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

Re: [TRNSYS-users] DERIVATIVES/setNumericalDerivative/getNumericalSolution vs. roll your own



On 2023-03-31 05:29, Damian Birchler via TRNSYS-users wrote:

Damian - awesome post and great questions! Let me start where you ended and work backwards.

Are we developing are in-house types in a "wrong" way?

I would argue that every model and every simulation is "wrong"...LOL We make simplifying assumptions and use solution techniques that do not perfectly represent the systems that we are modeling. Even something as accepted as a time step in TRNSYS is an approximation made to allow for a solution in a finite amount of time. The answer comes down to "How Wrong" is acceptable for your analysis.

Is DERIVATIVES & friends just

 	* A user-friendly utility that helps a type developer may use to
solve their ODEs

My opinion: Yes.

	* The preferred way of solving ODEs for overall convergence reasons
(by "overall" I mean system-wide; between all units)

Well it's not my preference and I've written thousands of TRNSYS models and hundreds that solve differential equations. I have found that solving them internally can greatly speed up a simulation as opposed to solving them externally. Remember that every time a TRNSYS Type gets called it updates it's outputs - which then requires the call (or at least a check) of every component that uses the outputs of that model - and then the models that use the outputs of the model that use the outputs of your model. I also prefer to solve them internally because I can build in some restraints that bound the physical problem. For example the outlet temperature of a cooling tower can't be any colder than the ambient conditions that the tower is communicating with. I also will routinely use other numerical techniques within my models (Newtons method for example) and having my black box model be able to solve its own problem internally can be very helpful. And I believe that there are times when solving the Diff Eq's internally may be the only practical way of doing it. Our sub-surface ground models literally solve tens of thousands of differential equations each timestep and some use advanced matrix methods. Not sure if I could even do that in TRNSYS using the external solver.

	* …for overall correctness reasons?

I don't have a PhD in mathematics so I'm not sure I'm qualified to answer that on a purely theoretical basis. But after 30+ years of using TRNSYS, calibrating our models and simulations to detailed measured data on everything from buildings to tanks to solar collectors to PCM storage devices, I can safely say that my real-world experience is that solving them internally is an extremely effective and accurate way of doing it. Is it "Right"? Don't know. But it's "Right Enough" for the accuracy that I'm looking for and at the end of the day that's what is important. Everything we model requires assumptions and I feel that this one is low enough on the spectrum that I'm comfortable with it. More comfortable with it then the assumption of constant fluid properties! LOL

Jeff
------------------------------------------------------------------------------------
Many of our in-house types as well as the few TESS types that I've
looked at solve their ODEs internally, using a wide variety of methods
from numerical to evaluating the explicit solution directly.

I'm very unclear about the (dis-)advantages of doing that vs. using
the TRNSYS built-in functionality of
DERIVATIVES/setNumericalDerivative/getNumericalSolution. Is
DERIVATIVES & friends just

 	* A user-friendly utility that helps a type developer may use to
solve their ODEs
	* The preferred way of solving ODEs for overall convergence reasons
(by "overall" I mean system-wide; between all units)
	* …for overall correctness reasons?

My question is "informed" by Wikipedia's page on DAEs:
https://en.wikipedia.org/wiki/Differential-algebraic_system_of_equations
[1].

After skimming through it, I was wondering what it means if (for the
purpose of this discussion) the ODEs of all units within a simulation
are hidden in the blackbox of their corresponding unit, then the
system to TRNSYS' eyes is completely "algebraic"…

Are we developing are in-house types in a "wrong" way?


--
----
Jeff Thornton
President
Thermal Energy System Specialists (TESS)
3 N. Pinckney Street - Suite 202
Madison WI 53703
(608) 274-2577
www.tess-inc.com