[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TRNSYS-users] TrnsysFunctions when using Powell's method

Dear Todd,
The example component that you sent us conflicts with one of the basic features of Solver 1: the organization of equations into blocks, in order to decide whether an input is a constant or depends explicitly on time. Those inputs that change with time are grouped into a set of simultaneous equations that are actually solved by Solver1. The list of inputs and outputs (used by getConnectedUnitNumber and getConnectedTypeNumber) is modified by Solver 1, and that is the reason why the example does not work.
I do not know if you still need to call these two functions in your new type, or if you got to them by trying to debug the problem. As these functions were developed for routines in the kernel, this conflict had not appeared before. I will be glad to find a solution if you need to use these functions in your type with Solver 1. In such case, I will appreciate if you can explain me a little better what your component is intended to do and we can plan the component for using the capabilities of Solver 1. 

Best regards,

Diego


Todd Houstein wrote:


Dear Diego (and anyone else interested),
Attached is a zip file which includes all relevant files:

1) The DLL, source code and proforma for Type153
Type153 is a test type that I have created. It has one input and two
outputs...
- The 1st OUTPUT is the UNIT NUMBER of the unit connected to the input (the
getConnectedUnitNumber function is used for this)
- The 2nd OUTPUT is the TYPE NUMBER of the unit connected to the input (the
getConnectedTypeNumber function is used for this)

2) A TRNSYS studio project (and associated files) named "test"
The project includes a Type153 with an arbitrary Type connected to its input
(which happens to be a Type14h), and its output connected to a Type65c
printer/plotter. When you run the simulation the resulting print/plot should
show the outputs of the Type153 to be 3 and 14 - the unit number and type
number of the unit connected to its input.

This works for me when using the Successive Substitution method, but not
Powell's method. I have found that when using Powell's method the
getConnectedUnitNumber function always returns a value of zero, and that the
getConnectedTypeNumber function produces a "range check error."

Thanks and regards,
Todd

-----------------------------------------------------------------
Todd Houstein  BEng(Hons)  MIEAust
President, Engineers Without Borders Australia - Tasmania chapter
www.ewb.org.au/tasmania

Committee member, Young Engineers Australia - Tasmania
*2005 is Engineers Australia's Year of the Young Engineer*
www.youngengineers.com.au

PhD Candidate
Hydrogen & Allied Renewable Technologies (HART) research team
www.eng.utas.edu.au/research/hart/hydrogen.html
School of Engineering
University of Tasmania
Private Bag 65 Hobart
Tasmania Australia 7001

Office: +61 3 6226 2094
Fax:    +61 3 6226 7863
Mobile: +61 4 1071 7177
----------------------------------------------------------------- 

-----Original Message-----
From: trnsys-users-bounces@engr.wisc.edu
[mailto:trnsys-users-bounces@engr.wisc.edu]On Behalf Of Diego A. Arias
Sent: Wednesday, 18 January 2006 6:29
To: toddh@utas.edu.au
Cc: trnsys-users@engr.wisc.edu
Subject: Re: [TRNSYS-users] TrnsysFunctions when using Powell's method


Dear Todd,

Could you please send me your project files where you are experiencing
this problems  I will be glad to take a look at them and see if there is
a problem in the formulation of Powell's method.
Best regards,

Diego

Todd Houstein wrote:


Hi everyone,
I have developed a TYPE that requires use of functions from the
"TrnsysFunctions.mod" module, including "getConnectedUnitNumber" and
"getConnectedTypeNumber". The calls to these functions work properly when
using the solution method "Successive substitution", but not "Powell's
method".

Specifically, when using Powell's method:
- getConnectedUnitNumber always returns a value of zero.
- getConnectedTypeNumber produces a "range check error."

Can anyone help me?

Thanks and regards,
Todd

-----------------------------------------------------------------
Todd Houstein  BEng(Hons)  MIEAust
President, Engineers Without Borders Australia - Tasmania chapter
www.ewb.org.au/tasmania

Committee member, Young Engineers Australia - Tasmania
*2005 is Engineers Australia's Year of the Young Engineer*
www.youngengineers.com.au

PhD Candidate
Hydrogen & Allied Renewable Technologies (HART) research team
www.eng.utas.edu.au/research/hart/hydrogen.html
School of Engineering
University of Tasmania
Private Bag 65 Hobart
Tasmania Australia 7001

Office: +61 3 6226 2094
Fax:    +61 3 6226 7863
Mobile: +61 4 1071 7177
-----------------------------------------------------------------

_______________________________________________
TRNSYS-users mailing list
TRNSYS-users@engr.wisc.edu
https://www.cae.wisc.edu/mailman/listinfo/trnsys-users





--

Diego A. Arias
TRNSYS Coordinator
Solar Energy Laboratory
University of Wisconsin - Madison
1500 Engineering Drive
Madison, WI 53706
_______________________________________________
TRNSYS-users mailing list
TRNSYS-users@engr.wisc.edu
https://www.cae.wisc.edu/mailman/listinfo/trnsys-users