Anton,
I have some brief insight that I would like to share in addition to Marcello's excellent comments.
First, please make sure that you have the "07-ProgrammersGuide.pdf" from the latest version of TRNSYS (17.01.0025). This piece of the documentation was completely re-written for version 17.1, so it may not make sense and lead to confusion if you have the documentation from 17.0.
Second, you are more than welcome to send an email via your local TRNSYS distributor to send to the TRNSYS developers. This Trnsys-Users mailing list is a discussion forum, and the questions are answered voluntarily.
Last, there is no "bomb" in the TRNSYS code. Most of the other simulation programs, as one of my colleagues mentioned, use fortran the same way (EnergyPlus, IES) and do not implement SAVE. It would be quite an extensive task as Marcello mentioned and not an efficient way to implement the code.
Best regards,
Matt Duffy
On 2013-03-15 07:45, marcello.caciolo@cofelyaxima-gdfsuez.com wrote:
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.comP 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