[TRNSYS-users] LU_JSTORE LU_OPENED

Thu Mar 22 12:57:34 PDT 2012

Dear Group,
I'm writing from a handicapped position, with me laptop out of reach,  
so I'm sorry if I get the exact names wrong.

Having compiled the existing source code of the Type25 Printer under  
my new type Type202, I'm loading it successfully into my project for  
testing.
I've copied the Type25a proforma for my type202 proforma.

After inserting a couple of message calls to see what's happening and  
to report on the state of some variables, I find the following  
puzzeling results (PS this type causes a 'FATAL' message to be called,  
which I have changed to 'Notice' to debug the type. The rest of the  
simulation then completes as expected.):

1) If I call and report the result of LU_PRINT it shows the the  
logical unit number assigned for the file output of this type  
(automatically assigned by trnsys when I drag the type into the field  
from the side tree) is correctly read in from Parameter 4 (in my case  
LU is 48. check.

2) In the code to 'check that the logical unit has been  
assigned' (which it has if I look at the deck with the ASSIGN  
statement to 48), the LUOK=getLogicalUnitIsOpen(48) returns FALSE even  
though this function should, as I understand it change the logical  
unit LU_OPENED variable by counting them even when it returns FALSE.  
My LU_OPENED and LU_JSTORE are both not returning 48 even though 48 is  
the last LU in this simulation. I think these data variables are used  
by trnsys before simulation to assign the LU numbers in the different  
types, but it seems that this is getting zero-ed when my type202 is  
called.

As a test, if I bring my type into the playing field twice and connect  
it up, I find that LU_JSTORE and LU_OPENED get increminted once as  
expected, so the type202 dll is remembering, but the starting point is  
wrong. It's getting lost somewhere.

Should I have to link all the types called externally from the userlib  
folder with one another?! surely this should be taken care of by  
linking with the trndll.dll during compilation.

Any ideas or hints?

PS You'll probably have to look at both the source code for Type25 and  
the source code for the trnfunctions module to understand what I'm  
talking about.

Sent from my iPhone with my 1 month daughter asleep on my chest with a  
cold.

On 22.03.2012, at 18:11, David BRADLEY <d.bradley at tess-inc.com> wrote:

> Jean,
> Fortran run-time libraries are a bit hard to define categorically;  
> essentially, there are some mathematical functions that are not  
> standard and that are contained in some additional libraries that  
> must be linked into the project. The most commonly known library is  
> the Lapack library, a lot of linear algebra functions that can be  
> referenced by a subroutine if you link in the Lapack run-time  
> libraries. The reason it is difficult to define which libraries you  
> need is that different compilers put their non-standard functions in  
> different libraries. As you probably know, if you get an "unresolved  
> external" error when you try to compile your code, this means that  
> there is routine or a function being referenced in your code that is  
> not recognized by the compiler and it needs to be provided  
> elsewhere. It sounds as though you have found a lot of them and that  
> you have solved the problem by finding alternative functions that  
> are native to G95 instead of ones that are referenced in a runtime  
> library. My apologies that I cannot offer a "here is how to fix the  
> problem" answer; hopefully some of the above information will help  
> guide you.
> Kind regards,
> David
>
>
> On 3/20/2012 00:32, jeannieboef wrote:
>> Dear Group,
>> My aim is to tweak the existing Type25 printer, so that I can  
>> dictate which connected inputs get printed AND to swich off the  
>> printer.
>>
>> But for now I am concerned with recompiling and running the Type25  
>> source code as a new type, Type202 as an external dll.
>>
>> Having found the guidance on using the g95 compiler, I must say it  
>> helped a lot. Additionally, it seems the following fixes where  
>> needed for the source code:
>>
>> JFIX must be substituted (this is an intel function which converts  
>> all sorts to Integer*4. I used INT().
>>
>> DMOD is a version of mod that should actually work, but did not. An  
>> extra function DMOD was set up in the TRNSYSFunctions module. This  
>> funtion returns the remainder of a division operation.
>>
>> Tabs in the source code are missleading as they are not the 5  
>> leading spaces required before the line continuation character.
>>
>> Variable format statements such as
>> 1001 FORMAT(A<maxUnitLength>,A1)
>> are not supported. I hard coded these, but other solutions are  
>> workable.
>>
>> Questions:
>> "Troubleshooting Multiple DLLs" chapter in the programmer guide...
>> what does "the Fortran run-time libraries" mean and where do I find  
>> the still lacking libraries and dlls to link in.
>> The EXE folder contains the release trndll.dll which I have linked  
>> as well as loads of other stuff not documented.
>>
>> Thanking you in advance,
>>
>> Jean
>>
>> PS yes I know I shouldn't use g95.
>>
>> Sent from my iPhone
>> _______________________________________________
>> TRNSYS-users mailing list
>> TRNSYS-users at cae.wisc.edu
>> https://mailman.cae.wisc.edu/listinfo/trnsys-users
>>
>
> -- 
> ***************************
> David BRADLEY
> Principal
> Thermal Energy Systems Specialists, LLC
> 22 North Carroll Street - suite 370
> Madison, WI  53703 USA
>
> P:+1.608.274.2577
> F:+1.608.278.1475
> d.bradley at tess-inc.com
>
> http://www.tess-inc.com
> http://www.trnsys.com
>