Hello,
I have a problem with the nonstandard Type 301, written by Per Isakson,
“matched flow collector model”. Depending on the timestep I get the
following error (it occurs only at timesteps less than ~45 minutes):
*** Fatal Error at time : 4792.090000
Generated by Unit : 7
Generated by Type : 301
TRNSYS Message 103 : The TRNSYS TYPE checking routine has found an
inconsistency in the specified component between the input file and the
information expected by the Type
Reported information : The component model has reported an unspecified
error. Please check the input file for possible sources of error.
TYPE301 : Ti4792.090 : Err 2000 : LE2_log ower flow
It is also depending on the Gain Constant of the included PID. (Small gain
constant -> error occurs even at large timesteps)
If I track the Type, I can´t find anthing unusual.
I found an old question about this on the mailing list, but no answer to it.
The old one is posted below.
Maybe someone has an answer or a good idea ?
Thanks in advance,
Sarah
“TRNSYS specialists
This is a question regarding the matched flow collector model, type 101
(formerly
type 52) (non-standard), written by Per O. Isakson, distributed by
TRANSSOLAR and
maybe others. The error 'LE2_log ower flow' stops the simulation (rarely,
but if it
does this is a mayor problem for our testing of solar systems). More details
about
the problem encountered are given below.
Questions:
Is there anyone (the author, transsolar, ?) who masters and maintains the
code?
If not, is there a more detailed description of the code, such as a
description of
the variables used? (I do not mean the parameter-list,
input/output-configuration
and physics involved: I do have that description).
Has anyone come across the same problem and identified a cause or even
solved it?
Problem:
I believe to have been facing problems with 'LE2_log ower flow' before when
there
was a small flow rate, which was for some reason not discovered as such and
eliminated by the routine. Recently the error occurred in a no-flow
situation. (No
flow in the timestep when the error occurred and no flow in at least 10
preceding
timesteps either). Looking at the code reveals that only one simple
condition in
subroutine Search_LE2_log can cause the error. However, printing out the
quantities
used by this routine generates more question than answers.
Note:
I have been working with that type for years and the longer I use it, the
more I
like it. It would be a petty if I'd have to give it up for a minor reason.
But that
code is not exactly like reading Harry Potter.
Peter“
Mit freundlichem Gruß,
Sarah Settler
Ökoplan
Büro für zeitgemäße Energieanwendung
Hummelsbütteler Weg 36
22339 Hamburg
T 040 5394143 F 040 5394144
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/attachments/20091012/4ca5635e/attachment-0005.htm>