Questa è una buona domanda e si tratta di un sacco. Ma prima, facciamo un passo indietro per un secondo.
L'idea di eseguire il debug di "linea per linea" deriva dai linguaggi di programmazione imperativi. Per "imperativo" intendo che un programma è semplicemente una sequenza di istruzioni da eseguire nell'ordine specificato.
Quando qualcuno esegue il debug di Java o Python, questo approccio "linea per linea" ha senso perché le affermazioni sono il modo fondamentale di rappresentare il comportamento. Questo approccio "linea per linea" potrebbe anche essere esteso alla modellazione di formalismi come i diagrammi a blocchi (ad esempio Simulink) perché, sebbene graficamente, sono anche imperativi (cioè costituiscono passi da compiere in un ordine specificato).
Ma Modelica è non una lingua imperativa. Non c'è idea di passi, dichiarazioni o istruzioni. Invece, abbiamo equazioni onnipresenti. Quindi, pensare in modo lineare al debug non funziona in Modelica. È vero che si potrebbe pensare a eseguire il debug del codice C generato da Modelica, ma in genere non è molto utile perché ha solo una parziale somiglianza con le equazioni.
Quindi, come si esegue il debug del codice Modelica? Bene, il debug del codice Modelica è in realtà il debug delle equazioni di Modelica. Normalmente, i modelli Modelica sono composti da componenti. Le equazioni che vengono generate quando i componenti sono connessi vengono generate automaticamente, quindi è possibile stipulare che il compilatore Modelica le elabori correttamente. Quindi, ciò che rimane sono le equazioni nei modelli dei componenti.
Il modo più semplice per avvicinarsi a questo è testare ciascun componente singolarmente (o almeno nei modelli più piccoli possibili). Dico spesso che provare a eseguire il debug di componenti Modelica lanciandoli tutti insieme in un modello grande è come ascoltare un'orchestra e cercare di capire l'unico strumento che è stonato. Il fatto che queste equazioni in Modelica tendano a formare sistemi simultanei di equazioni significa che gli errori, quando si verificano, possono propagarsi immediatamente a un numero di variabili.
Quindi la soluzione migliore è passare e creare test per ogni singolo componente e verificare il comportamento del componente. La mia esperienza è che quando lo fai, puoi rintracciare ed eliminare i bug abbastanza facilmente.
Aggiornamento: non è necessario aggiungere output ai modelli di componenti di altre persone per eseguirne il debug. Un output può essere creato a qualsiasi livello, ad es.
model SystemModel
SomeoneElsesComponent a;
SomeOtherGuysComponent b;
end SystemModel;
model SystemModel_Debug
extends SystemModel;
output Real someNestedSignalFromA = a.someSubsystem.someSubcomponent.someSignal;
output Real someOtherNestedSignalFromB = b.anotherSubsystem.anotherSignal;
end SystemModel_Debug;
Naturalmente, questo diventa poco pratico se si dispone di più istanze di un componente di segnale. In questi casi, ammetto che è più semplice modificare il modello sottostante. Ma se fanno i loro modelli replaceable
, puoi usare lo stesso trucco di cui sopra (estende il loro modello, aggiungi un mucchio di output personalizzati e poi il tuo modello al posto dell'originale).
Vedi anche questo documento: http://dx.doi.org/10.3384/ecp12076443 – matth