[TRNSYS-users] Types programming: Types-Kernel interface explanation

Fri Mar 15 06:10:02 PDT 2013

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 at 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 at cofelyaxima-gdfsuez.com [1] 
> 
> P PENSEZ
L'ENVIRONNEMENT AVANT D'IMPRIMER CE MESSAGE 
> 
> DE :
trnsys-users-bounces at cae.wisc.edu
[mailto:trnsys-users-bounces at cae.wisc.edu] DE LA PART DE Soppelsa
Anton
> ENVOY : vendredi 15 mars 2013 11:34
> :
trnsys-users at 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
[2] . 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

Links:
------
[1]
mailto:prenom.nom at aximaseitha-gdfsuez.com
[2]
http://stackoverflow.com/questions/15414277/where-does-fortran-store-local-variables
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/attachments/20130315/55d582d6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 4267 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/attachments/20130315/55d582d6/attachment-0001.jpg>