Dear Anton,
You can find a brief description of the successive substitutions algorithm implemented by TRNSYS in the chapter 6 of TRNSYS documentation (page 33).
In my understanding, the system of equation solved at each time step is X = F(X, t), where X is the vector of all variables (inputs and outputs of all the types).
Have a nice week end!
Marcello Caciolo
Responsable Outils et Méthodes d'Analyse Energétique
Cellule Efficacité Energétique et Environnementale - Pôle Projets et Réalisations
46 Boulevard de la Prairie au Duc
BP 40119 - 44201 Nantes Cedex 02
Tél.: +33 02 40 41 06 57
marcello.caciolo@cofelyaxima-gdfsuez.com
P Pensez à l'environnement avant d'imprimer ce message
De : trnsys-users-bounces@cae.wisc.edu [mailto:trnsys-users-bounces@cae.wisc.edu] De la part de Soppelsa Anton
Envoyé : vendredi 15 mars 2013 16:55
À : 'TRNSYS users mailing list at the Solar Energy Lab, UW-Madison'
Objet : Re: [TRNSYS-users] Types programming: Types-Kernel interface explanation
Dear Marcello,
thank you very much for your kind answer.
I found that the successive substitutions algorithm is a method to solve non-linear equations. So my question is: what system of equations is TRNSYS trying to solve?
Am I correct if I think that TRNSYS builds a big system of equation considering each type as something which behaves like described in my previous mail (maybe without the f function, but in that case we would be talking of static mappings nothing dynamic)?
Are these topic covered in a section of the TRNSYS manual?
Sincerely,
AS
From: trnsys-users-bounces@cae.wisc.edu [mailto:trnsys-users-bounces@cae.wisc.edu] On Behalf Of marcello.caciolo@cofelyaxima-gdfsuez.com
Sent: Friday, 15 March, 2013 13:46
To: trnsys-users@cae.wisc.edu
Subject: Re: [TRNSYS-users] Types programming: Types-Kernel interface explanation
Dear Anton,
A quick answer to your questions :
1) and 2) During each time step, TRNSYS calls sequentially each type and update input variables of other types with calculated values from the current type, repeating this operation until output variables do not change anymore (successive substitutions algorithm).
The number of calls to a type in each time step is not limited to 3: I think you get confused by the table page 7-78 of the programmer’s guide, representing just un example assuming that convergence is reached for each time step at the second iteration.
3) I have never used the dTdt vector, than I cannot answer to you on this specific point
4) A TRNSYS Types is basically a procedure which computes an array of outputs knowing the following array:
· An input array, provided by TRNSYS when calling the type.
· A parameter array, which is constant (TRNSYS passes it to the type, but normally it should not change from call to call)
· A static storage array, defined by the type during the initialization call, which is basically an additional parameter array
· A dynamic storage array, which can be used to store variables between iterations and time steps (your state vector, I imagine?)
Derivative of variables can also be computed by TRNSYS and used by a type but, as I told before, I am not very familiar with this.
For your second point you should consider an issue common to many old codes : TRNSYS was first developed in FORTRAN 77, which considers all variables with the attribute SAVE (static variables, in C/C++ terms). Modern FORTRAN compilers do not consider any more all variables as static (you should define a variable explicitly with SAVE attribute to define a static variable), but as there are many old codes written in FORTRAN, they practically always give the possibility to use this old characteristics by a compiler directive (and I would be very surprised if next versions of Intel Visual FORTRAN would not give this possibility).
You are right, this is not a good programming practice, but the alternative would be to take all the code and insert the keyword SAVE to all variable definition. I understand that TRNSYS developers has better things to do...:-) By the way, the only problem with static variables is that you cannot optimize storage of data, but in my experience TRNSYS simulations are far from using much RAM.
Anyway, this feature explains the reason because, for example, if there is only one unit of the same type, you are not obliged to reread each time the parameters (which is the meaning of the code you sent to the forum).
Just a final note about INFO array : it is now possible (and even recommended) to use directly access functions to read inputs, parameters and storage arrays, for example in order to read the i-th input you can use the statement var = getInputValue(i), to read the i-th parameter : par = getParameterValue(i), etc…
I hope this helps.
Best regards,
Marcello Caciolo
Responsable Outils et Méthodes d'Analyse Energétique
Cellule Efficacité Energétique et Environnementale - Pôle Projets et Réalisations
46 Boulevard de la Prairie au Duc
BP 40119 - 44201 Nantes Cedex 02
Tél.: +33 02 40 41 06 57
marcello.caciolo@cofelyaxima-gdfsuez.com
P Pensez à l'environnement avant d'imprimer ce message
De : trnsys-users-bounces@cae.wisc.edu [mailto:trnsys-users-bounces@cae.wisc.edu] De la part de Soppelsa Anton
Envoyé : vendredi 15 mars 2013 11:34
À : trnsys-users@cae.wisc.edu
Objet : [TRNSYS-users] Types programming: Types-Kernel interface explanation
Dear TRNSYS users,
I have been looking for a while to the seventh section of the TRNSYS 17 manual in order to understand how and why the kernel calls a type in the way it does.
Notwithstanding my experience with simulation software like Matlab/Simulink, Scilab/XCos, Ptolemy II, I still have difficulties in understanding some aspects of the TRNSYS callbacks interface, e.g.:
1) What’s the purpose of the inter-step calls (iterations)
2) Why they need to be exactly 3 (as I understood from the manual).
3) How the kernel make use of the vector dTdt (which I would have called dxdt).
4) Whether my understanding that Types can be used to implement the following mathematical models: y = g(x, u, t), dxdt = fc(x, u, t) (or x(t+1) = fd(x(t), u(t), t) in case of discrete systems), where t is the time, u is the input vector, x is the state vector and y is the output vector is correct.
Can anybody suggest me what is the right section of the manual to find an answer to these questions? I had no luck reading the programmer´s guide section of the manual.
A second point is that I found puzzling the code example published therein. In the first time I though that my doubts where related to my scarce knowledge of the Fortran language (I am a C/C++ programmer) so I raised a point in a programmer community http://stackoverflow.com/questions/15414277/where-does-fortran-store-local-variables . It turned out that the code published in the manual (which contains a pattern which I noticed has widespread to many other types) seems to rely on a Fortran language “feature” which is considered “bad programming practice”, is compiler-dependent and may not be supported any more in the future.
As it seem to me impossible that such a “bomb” is present in the program without affecting the TRNSYS community I kindly ask the help of a TRNSYS expert to clarify this point.
Does anybody know if there a trnsys-devel mailing list?
Sincerely,
AS