daetools-users Mailing List for DAE Tools Project
Object-oriented equation-based modelling and optimisation software
Brought to you by:
ciroki
Menu
▾
▴
daetools-users — DAE Tools user list
This list is closed, nobody may subscribe to it.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
(22) |
Sep
(37) |
Oct
(11) |
Nov
|
Dec
(9) |
| 2014 |
Jan
(13) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(13) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(30) |
Jun
(1) |
Jul
(4) |
Aug
(12) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
(5) |
Mar
(8) |
Apr
(11) |
May
(5) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(10) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: StUstD <st...@gm...> - 2018-03-09 12:13:20
|
Hi Dragan: Thanks! Indeed, it seems DAETools can handle discrete-time conditions without problem. This may one of a few core functions on top of which the rest of a System Dynamics (SD) functionality can be built. As said I'm not an expert of all the SD tools available but I think your tool is potentially much more powerful: I don't know of any SD tool that handles DAE's, only ODE's. Thereby, the 'charm' of regular SD tools is their GUI which makes modeling for non-programmers a lot easier. But nothing beats a good API. BTW Simantics <http://sysdyn.simantics.org> is a free fully functional SD tool for Windows that you may want to try out. With the 'new' functionality I'll keep building my model and keep you informed as I go. In the meantime don't hesitate to contact me if you want some brainstorming or feedback on anything. Regards, -- Henk On Fri, Mar 9, 2018 at 12:04 PM, Dragan Nikolic <dra...@gm...> wrote: > Hi Henk, > > It is just a matter of sequence of calls in daetools: first the > daeModel-derived classes __init__ is called, then > SetUpParametersAndDomains, SetUpVariables and finally DeclareEquations. > Thus, you need to set a value of tau_jump parameter in > SetUpParametersAndDomains function, i.e.: > self.m.tau_jump.SetValue(2.0*s) > Also, you forgot self.tau.dt for Time equation (you set an initial > condition so I suppose you wanted it to be a differential variable): > eq = self.CreateEquation("Time", "Differential equation to calculate > the time elapsed in the process.") > eq.Residual = self.tau.dt() - 1 > Have a look on the attached file with the changes I made. > > So, I guess you try to test the functionality to have discrete events > triggered and variables updated with constants and parameter values. That > will work with no problems I think. > Perhaps it would be a good idea to create an API (functions and classes) > to wrap the functionality required for system dynamics. That API can > internally use the basic modelling concepts (parameters, variables, > discontinuous equations and OnCondition handlers etc.). I could check the > documentation for some of the popular software. > > Cheers > Dragan > > On 09/03/18 10:51, StUstD wrote: > >> Hi Dragan: >> >> Thanks, that works! 'itau' is discretely incremented event with >> ON_CONDITION( Time()==itau, ..., eventTolerance=0.0 ). >> >> However, >> >> 1) I've not been able to eliminate a second equation: DAETools wants >> (understandably) an equal number of equations as variables... >> >> 2) Expanding the problem, I have no success in trying to discretely >> update 'tau' at the condition with a daeParameter. See file attached. >> >> Regards, >> Henk >> >> >> >> On Thu, Mar 8, 2018 at 5:19 PM, Dragan Nikolic <dra...@gm... >> <mailto:dra...@gm...>> wrote: >> >> Hi Henk, >> >> It's just a typo, the argument of ON_CONDITION function should be >> switchToStates not switchToState. It works well.then. >> >> Also, you do not need to add a separate differential equation. You >> can just set: >> >> def SetUpVariables(self): >> self.m.itau.AssignValue(0.0) >> as it is in the attached file. But, it depends what do you need >> itau for. >> >> Cheers >> Dragan >> >> >> On 08/03/18 14:34, StUstD wrote: >> >> Hi Dragan: >> >> Please find attached the modified "whats_the_time.py" example >> that includes and tests the discrete-time conditional you >> suggested. >> >> Find below the simulation error message I obtain. Anything >> wrong in my specification? >> >> Regards, >> -- Henk >> >> ************************************************************ >> *********** >> >> Version: 1.8.0 >> >> Copyright: Dragan Nikolic, 2017 >> >> Homepage: http://www.daetools.com >> >> @ @ >> >> @ @@@@@ @@@@@ @@@@@ @@@@@ @@@@@ @ @@@@@ >> >> @@@@@@ @ @ @ @ @ @ @ @ @ @ >> >> @ @ @@@@@@ @@@@@@ @ @ @ @ @ @ @@@@@ >> >> @ @ @ @ @ @ @ @ @ @ @ @ >> >> @@@@@@ @@@@@@ @@@@@ @@@ @@@@@ @@@@@ @@@@ @@@@@ >> >> ************************************************************ >> *********** >> >> DAE Tools is free software: you can redistribute it and/or modify >> >> it under the terms of the GNU General Public License version 3 >> >> as published by the Free Software Foundation. >> >> DAE Tools is distributed in the hope that it will be useful, >> >> but WITHOUT ANY WARRANTY; without even the implied warranty of >> >> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> >> General Public License for more details. >> >> You should have received a copy of the GNU General Public License >> >> along with this program. If not, see >> <http://www.gnu.org/licenses>. >> >> ************************************************************ >> *********** >> >> Creating the system... >> >> File >> "/home/hjansen/workspace/gitspace/Contryx/projects/enterpris >> e/CxSim/inst/python/3/lib/python3.6/site-packages/daetools- >> 1.8.0-py3.6-linux-x86_64.egg/daetools/dae_simulator/simulator.py", >> line 276, in run >> >> self.simulation.Initialize(self.daesolver, self.datareporter, >> self.log) >> >> File >> "/home/hjansen/workspace/gitspace/Contryx/projects/explorati >> on/00-TaE-Python/src/simulation/daetools/discrete_signal_tri >> al/discrete_signal_01.py", >> line 146, in DeclareEquations >> >> eventTolerance = 0.00001) >> >> Python argument types in >> >> daeModel.ON_CONDITION(modTutorial, daeCondition) >> >> did not match C++ signature: >> >> ON_CONDITION(dae::core::daeModel {lvalue} self, >> dae::core::daeCondition condition, boost::python::list >> switchToStates=[], boost::python::list setVariableValues=[], >> boost::python::list triggerEvents=[], boost::python::list >> userDefinedActions=[], double eventTolerance=0.0) >> >> >> >> On Wed, Mar 7, 2018 at 2:49 PM, Dragan Nikolic >> <dra...@gm... <mailto:dra...@gm...> >> <mailto:dra...@gm... <mailto:dra...@gm...>>> >> >> wrote: >> >> Hi, >> >> Well, it is a bit difficult because of the way the >> equation-based >> systems are solved numerically but it might work. >> >> If you wish to change a model variable you can use >> daeModel.ON_CONDITION function (have a look on tutorials >> 5, 14). >> If iT is a model variable, you can put the following in the >> function DeclareEquations: >> >> self.ON_CONDITION(Time() > iT, switchToStates = [], >> setVariableValues = [iT, >> iT+1], # >> here you may need to use self.iT() >> triggerEvents = [], >> userDefinedActions = []) >> >> But, you need to be careful here: your condition Time() > >> iT will >> be triggered EVERY time step once the simulation time becomes >> greater than iT. However, you change it each time the >> condition is >> satisfied, so it might work. Please check and let me know, >> I am >> curious if it works or not. >> >> Cheers >> Dragan >> >> >> >> On 07/03/18 11:45, StUstD wrote: >> >> How is it possible to create a discrete-time signal, >> e.g. a >> counter (in pseudo code): >> >> initial Time = 0 >> iT = 1 # counter >> >> if Time() > iT: >> iT += 1 >> endif >> >> Thanks. >> >> >> >> ----------------------------- >> ------------------------------------------------- >> Check out the vibrant tech community on one of the >> world's most >> engaging tech sites, Slashdot.org! >> http://sdm.link/slashdot >> >> >> _______________________________________________ >> daetools-users mailing list >> dae...@li... >> <mailto:dae...@li...> >> <mailto:dae...@li... >> <mailto:dae...@li...>> >> https://lists.sourceforge.net/lists/listinfo/daetools-users >> <https://lists.sourceforge.net/lists/listinfo/daetools-users> >> <https://lists.sourceforge.ne >> t/lists/listinfo/daetools-users >> <https://lists.sourceforge.net/lists/listinfo/daetools-users>> >> >> >> >> >> >> > |
|
From: Dragan N. <dra...@gm...> - 2018-03-09 11:04:24
|
Hi Henk,
It is just a matter of sequence of calls in daetools: first the
daeModel-derived classes __init__ is called, then
SetUpParametersAndDomains, SetUpVariables and finally DeclareEquations.
Thus, you need to set a value of tau_jump parameter in
SetUpParametersAndDomains function, i.e.:
self.m.tau_jump.SetValue(2.0*s)
Also, you forgot self.tau.dt for Time equation (you set an initial
condition so I suppose you wanted it to be a differential variable):
eq = self.CreateEquation("Time", "Differential equation to
calculate the time elapsed in the process.")
eq.Residual = self.tau.dt() - 1
Have a look on the attached file with the changes I made.
So, I guess you try to test the functionality to have discrete events
triggered and variables updated with constants and parameter values.
That will work with no problems I think.
Perhaps it would be a good idea to create an API (functions and classes)
to wrap the functionality required for system dynamics. That API can
internally use the basic modelling concepts (parameters, variables,
discontinuous equations and OnCondition handlers etc.). I could check
the documentation for some of the popular software.
Cheers
Dragan
On 09/03/18 10:51, StUstD wrote:
> Hi Dragan:
>
> Thanks, that works! 'itau' is discretely incremented event with
> ON_CONDITION( Time()==itau, ..., eventTolerance=0.0 ).
>
> However,
>
> 1) I've not been able to eliminate a second equation: DAETools wants
> (understandably) an equal number of equations as variables...
>
> 2) Expanding the problem, I have no success in trying to discretely
> update 'tau' at the condition with a daeParameter. See file attached.
>
> Regards,
> Henk
>
>
>
> On Thu, Mar 8, 2018 at 5:19 PM, Dragan Nikolic <dra...@gm...
> <mailto:dra...@gm...>> wrote:
>
> Hi Henk,
>
> It's just a typo, the argument of ON_CONDITION function should be
> switchToStates not switchToState. It works well.then.
>
> Also, you do not need to add a separate differential equation. You
> can just set:
>
> def SetUpVariables(self):
> self.m.itau.AssignValue(0.0)
> as it is in the attached file. But, it depends what do you need
> itau for.
>
> Cheers
> Dragan
>
>
> On 08/03/18 14:34, StUstD wrote:
>
> Hi Dragan:
>
> Please find attached the modified "whats_the_time.py" example
> that includes and tests the discrete-time conditional you
> suggested.
>
> Find below the simulation error message I obtain. Anything
> wrong in my specification?
>
> Regards,
> -- Henk
>
> ***********************************************************************
>
> Version: 1.8.0
>
> Copyright: Dragan Nikolic, 2017
>
> Homepage: http://www.daetools.com
>
> @ @
>
> @ @@@@@ @@@@@ @@@@@ @@@@@ @@@@@ @ @@@@@
>
> @@@@@@ @ @ @ @ @ @ @ @ @ @
>
> @ @ @@@@@@ @@@@@@ @ @ @ @ @ @ @@@@@
>
> @ @ @ @ @ @ @ @ @ @ @ @
>
> @@@@@@ @@@@@@ @@@@@ @@@ @@@@@ @@@@@ @@@@ @@@@@
>
> ***********************************************************************
>
> DAE Tools is free software: you can redistribute it and/or modify
>
> it under the terms of the GNU General Public License version 3
>
> as published by the Free Software Foundation.
>
> DAE Tools is distributed in the hope that it will be useful,
>
> but WITHOUT ANY WARRANTY; without even the implied warranty of
>
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>
> General Public License for more details.
>
> You should have received a copy of the GNU General Public License
>
> along with this program. If not, see
> <http://www.gnu.org/licenses>.
>
> ***********************************************************************
>
> Creating the system...
>
> File
> "/home/hjansen/workspace/gitspace/Contryx/projects/enterprise/CxSim/inst/python/3/lib/python3.6/site-packages/daetools-1.8.0-py3.6-linux-x86_64.egg/daetools/dae_simulator/simulator.py",
> line 276, in run
>
> self.simulation.Initialize(self.daesolver, self.datareporter,
> self.log)
>
> File
> "/home/hjansen/workspace/gitspace/Contryx/projects/exploration/00-TaE-Python/src/simulation/daetools/discrete_signal_trial/discrete_signal_01.py",
> line 146, in DeclareEquations
>
> eventTolerance = 0.00001)
>
> Python argument types in
>
> daeModel.ON_CONDITION(modTutorial, daeCondition)
>
> did not match C++ signature:
>
> ON_CONDITION(dae::core::daeModel {lvalue} self,
> dae::core::daeCondition condition, boost::python::list
> switchToStates=[], boost::python::list setVariableValues=[],
> boost::python::list triggerEvents=[], boost::python::list
> userDefinedActions=[], double eventTolerance=0.0)
>
>
>
> On Wed, Mar 7, 2018 at 2:49 PM, Dragan Nikolic
> <dra...@gm... <mailto:dra...@gm...>
> <mailto:dra...@gm... <mailto:dra...@gm...>>>
> wrote:
>
> Hi,
>
> Well, it is a bit difficult because of the way the
> equation-based
> systems are solved numerically but it might work.
>
> If you wish to change a model variable you can use
> daeModel.ON_CONDITION function (have a look on tutorials
> 5, 14).
> If iT is a model variable, you can put the following in the
> function DeclareEquations:
>
> self.ON_CONDITION(Time() > iT, switchToStates = [],
> setVariableValues = [iT,
> iT+1], #
> here you may need to use self.iT()
> triggerEvents = [],
> userDefinedActions = [])
>
> But, you need to be careful here: your condition Time() >
> iT will
> be triggered EVERY time step once the simulation time becomes
> greater than iT. However, you change it each time the
> condition is
> satisfied, so it might work. Please check and let me know,
> I am
> curious if it works or not.
>
> Cheers
> Dragan
>
>
>
> On 07/03/18 11:45, StUstD wrote:
>
> How is it possible to create a discrete-time signal,
> e.g. a
> counter (in pseudo code):
>
> initial Time = 0
> iT = 1 # counter
>
> if Time() > iT:
> iT += 1
> endif
>
> Thanks.
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the
> world's most
> engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot
>
>
> _______________________________________________
> daetools-users mailing list
> dae...@li...
> <mailto:dae...@li...>
> <mailto:dae...@li...
> <mailto:dae...@li...>>
> https://lists.sourceforge.net/lists/listinfo/daetools-users
> <https://lists.sourceforge.net/lists/listinfo/daetools-users>
>
> <https://lists.sourceforge.net/lists/listinfo/daetools-users
> <https://lists.sourceforge.net/lists/listinfo/daetools-users>>
>
>
>
>
>
|
|
From: StUstD <st...@gm...> - 2018-03-09 09:52:05
|
Hi Dragan: Thanks, that works! 'itau' is discretely incremented event with ON_CONDITION( Time()==itau, ..., eventTolerance=0.0 ). However, 1) I've not been able to eliminate a second equation: DAETools wants (understandably) an equal number of equations as variables... 2) Expanding the problem, I have no success in trying to discretely update 'tau' at the condition with a daeParameter. See file attached. Regards, Henk On Thu, Mar 8, 2018 at 5:19 PM, Dragan Nikolic <dra...@gm...> wrote: > Hi Henk, > > It's just a typo, the argument of ON_CONDITION function should be > switchToStates not switchToState. It works well.then. > > Also, you do not need to add a separate differential equation. You can > just set: > > def SetUpVariables(self): > self.m.itau.AssignValue(0.0) > as it is in the attached file. But, it depends what do you need itau for. > > Cheers > Dragan > > > On 08/03/18 14:34, StUstD wrote: > >> Hi Dragan: >> >> Please find attached the modified "whats_the_time.py" example that >> includes and tests the discrete-time conditional you suggested. >> >> Find below the simulation error message I obtain. Anything wrong in my >> specification? >> >> Regards, >> -- Henk >> >> *********************************************************************** >> >> Version: 1.8.0 >> >> Copyright: Dragan Nikolic, 2017 >> >> Homepage: http://www.daetools.com >> >> @ @ >> >> @ @@@@@ @@@@@ @@@@@ @@@@@ @@@@@ @ @@@@@ >> >> @@@@@@ @ @ @ @ @ @ @ @ @ @ >> >> @ @ @@@@@@ @@@@@@ @ @ @ @ @ @ @@@@@ >> >> @ @ @ @ @ @ @ @ @ @ @ @ >> >> @@@@@@ @@@@@@ @@@@@ @@@ @@@@@ @@@@@ @@@@ @@@@@ >> >> *********************************************************************** >> >> DAE Tools is free software: you can redistribute it and/or modify >> >> it under the terms of the GNU General Public License version 3 >> >> as published by the Free Software Foundation. >> >> DAE Tools is distributed in the hope that it will be useful, >> >> but WITHOUT ANY WARRANTY; without even the implied warranty of >> >> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> >> General Public License for more details. >> >> You should have received a copy of the GNU General Public License >> >> along with this program. If not, see <http://www.gnu.org/licenses>. >> >> *********************************************************************** >> >> Creating the system... >> >> File "/home/hjansen/workspace/gitspace/Contryx/projects/enterpris >> e/CxSim/inst/python/3/lib/python3.6/site-packages/daetoo >> ls-1.8.0-py3.6-linux-x86_64.egg/daetools/dae_simulator/simulator.py", >> line 276, in run >> >> self.simulation.Initialize(self.daesolver, self.datareporter, self.log) >> >> File "/home/hjansen/workspace/gitspace/Contryx/projects/explorati >> on/00-TaE-Python/src/simulation/daetools/discrete_signal_trial/discrete_signal_01.py", >> line 146, in DeclareEquations >> >> eventTolerance = 0.00001) >> >> Python argument types in >> >> daeModel.ON_CONDITION(modTutorial, daeCondition) >> >> did not match C++ signature: >> >> ON_CONDITION(dae::core::daeModel {lvalue} self, dae::core::daeCondition >> condition, boost::python::list switchToStates=[], boost::python::list >> setVariableValues=[], boost::python::list triggerEvents=[], >> boost::python::list userDefinedActions=[], double eventTolerance=0.0) >> >> >> >> On Wed, Mar 7, 2018 at 2:49 PM, Dragan Nikolic <dra...@gm... >> <mailto:dra...@gm...>> wrote: >> >> Hi, >> >> Well, it is a bit difficult because of the way the equation-based >> systems are solved numerically but it might work. >> >> If you wish to change a model variable you can use >> daeModel.ON_CONDITION function (have a look on tutorials 5, 14). >> If iT is a model variable, you can put the following in the >> function DeclareEquations: >> >> self.ON_CONDITION(Time() > iT, switchToStates = [], >> setVariableValues = [iT, iT+1], # >> here you may need to use self.iT() >> triggerEvents = [], >> userDefinedActions = []) >> >> But, you need to be careful here: your condition Time() > iT will >> be triggered EVERY time step once the simulation time becomes >> greater than iT. However, you change it each time the condition is >> satisfied, so it might work. Please check and let me know, I am >> curious if it works or not. >> >> Cheers >> Dragan >> >> >> >> On 07/03/18 11:45, StUstD wrote: >> >> How is it possible to create a discrete-time signal, e.g. a >> counter (in pseudo code): >> >> initial Time = 0 >> iT = 1 # counter >> >> if Time() > iT: >> iT += 1 >> endif >> >> Thanks. >> >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> >> _______________________________________________ >> daetools-users mailing list >> dae...@li... >> <mailto:dae...@li...> >> https://lists.sourceforge.net/lists/listinfo/daetools-users >> <https://lists.sourceforge.net/lists/listinfo/daetools-users> >> >> >> >> > |
|
From: Dragan N. <dra...@gm...> - 2018-03-08 16:20:05
|
Hi Henk,
It's just a typo, the argument of ON_CONDITION function should be
switchToStates not switchToState. It works well.then.
Also, you do not need to add a separate differential equation. You can
just set:
def SetUpVariables(self):
self.m.itau.AssignValue(0.0)
as it is in the attached file. But, it depends what do you need itau for.
Cheers
Dragan
On 08/03/18 14:34, StUstD wrote:
> Hi Dragan:
>
> Please find attached the modified "whats_the_time.py" example that
> includes and tests the discrete-time conditional you suggested.
>
> Find below the simulation error message I obtain. Anything wrong in my
> specification?
>
> Regards,
> -- Henk
>
> ***********************************************************************
>
> Version: 1.8.0
>
> Copyright: Dragan Nikolic, 2017
>
> Homepage: http://www.daetools.com
>
> @ @
>
> @ @@@@@ @@@@@ @@@@@ @@@@@ @@@@@ @ @@@@@
>
> @@@@@@ @ @ @ @ @ @ @ @ @ @
>
> @ @ @@@@@@ @@@@@@ @ @ @ @ @ @ @@@@@
>
> @ @ @ @ @ @ @ @ @ @ @ @
>
> @@@@@@ @@@@@@ @@@@@ @@@ @@@@@ @@@@@ @@@@ @@@@@
>
> ***********************************************************************
>
> DAE Tools is free software: you can redistribute it and/or modify
>
> it under the terms of the GNU General Public License version 3
>
> as published by the Free Software Foundation.
>
> DAE Tools is distributed in the hope that it will be useful,
>
> but WITHOUT ANY WARRANTY; without even the implied warranty of
>
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>
> General Public License for more details.
>
> You should have received a copy of the GNU General Public License
>
> along with this program. If not, see <http://www.gnu.org/licenses>.
>
> ***********************************************************************
>
> Creating the system...
>
> File
> "/home/hjansen/workspace/gitspace/Contryx/projects/enterprise/CxSim/inst/python/3/lib/python3.6/site-packages/daetools-1.8.0-py3.6-linux-x86_64.egg/daetools/dae_simulator/simulator.py",
> line 276, in run
>
> self.simulation.Initialize(self.daesolver, self.datareporter, self.log)
>
> File
> "/home/hjansen/workspace/gitspace/Contryx/projects/exploration/00-TaE-Python/src/simulation/daetools/discrete_signal_trial/discrete_signal_01.py",
> line 146, in DeclareEquations
>
> eventTolerance = 0.00001)
>
> Python argument types in
>
> daeModel.ON_CONDITION(modTutorial, daeCondition)
>
> did not match C++ signature:
>
> ON_CONDITION(dae::core::daeModel {lvalue} self,
> dae::core::daeCondition condition, boost::python::list
> switchToStates=[], boost::python::list setVariableValues=[],
> boost::python::list triggerEvents=[], boost::python::list
> userDefinedActions=[], double eventTolerance=0.0)
>
>
>
> On Wed, Mar 7, 2018 at 2:49 PM, Dragan Nikolic <dra...@gm...
> <mailto:dra...@gm...>> wrote:
>
> Hi,
>
> Well, it is a bit difficult because of the way the equation-based
> systems are solved numerically but it might work.
>
> If you wish to change a model variable you can use
> daeModel.ON_CONDITION function (have a look on tutorials 5, 14).
> If iT is a model variable, you can put the following in the
> function DeclareEquations:
>
> self.ON_CONDITION(Time() > iT, switchToStates = [],
> setVariableValues = [iT, iT+1], #
> here you may need to use self.iT()
> triggerEvents = [],
> userDefinedActions = [])
>
> But, you need to be careful here: your condition Time() > iT will
> be triggered EVERY time step once the simulation time becomes
> greater than iT. However, you change it each time the condition is
> satisfied, so it might work. Please check and let me know, I am
> curious if it works or not.
>
> Cheers
> Dragan
>
>
>
> On 07/03/18 11:45, StUstD wrote:
>
> How is it possible to create a discrete-time signal, e.g. a
> counter (in pseudo code):
>
> initial Time = 0
> iT = 1 # counter
>
> if Time() > iT:
> iT += 1
> endif
>
> Thanks.
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> daetools-users mailing list
> dae...@li...
> <mailto:dae...@li...>
> https://lists.sourceforge.net/lists/listinfo/daetools-users
> <https://lists.sourceforge.net/lists/listinfo/daetools-users>
>
>
>
|
|
From: StUstD <st...@gm...> - 2018-03-08 13:34:38
|
Hi Dragan: Please find attached the modified "whats_the_time.py" example that includes and tests the discrete-time conditional you suggested. Find below the simulation error message I obtain. Anything wrong in my specification? Regards, -- Henk *********************************************************************** Version: 1.8.0 Copyright: Dragan Nikolic, 2017 Homepage: http://www.daetools.com @ @ @ @@@@@ @@@@@ @@@@@ @@@@@ @@@@@ @ @@@@@ @@@@@@ @ @ @ @ @ @ @ @ @ @ @ @ @@@@@@ @@@@@@ @ @ @ @ @ @ @@@@@ @ @ @ @ @ @ @ @ @ @ @ @ @@@@@@ @@@@@@ @@@@@ @@@ @@@@@ @@@@@ @@@@ @@@@@ *********************************************************************** DAE Tools is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License version 3 as published by the Free Software Foundation. DAE Tools is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses>. *********************************************************************** Creating the system... File "/home/hjansen/workspace/gitspace/Contryx/projects/enterprise/CxSim/inst/python/3/lib/python3.6/site-packages/daetools-1.8.0-py3.6-linux-x86_64.egg/daetools/dae_simulator/simulator.py", line 276, in run self.simulation.Initialize(self.daesolver, self.datareporter, self.log) File "/home/hjansen/workspace/gitspace/Contryx/projects/exploration/00-TaE-Python/src/simulation/daetools/discrete_signal_trial/discrete_signal_01.py", line 146, in DeclareEquations eventTolerance = 0.00001) Python argument types in daeModel.ON_CONDITION(modTutorial, daeCondition) did not match C++ signature: ON_CONDITION(dae::core::daeModel {lvalue} self, dae::core::daeCondition condition, boost::python::list switchToStates=[], boost::python::list setVariableValues=[], boost::python::list triggerEvents=[], boost::python::list userDefinedActions=[], double eventTolerance=0.0) On Wed, Mar 7, 2018 at 2:49 PM, Dragan Nikolic <dra...@gm...> wrote: > Hi, > > Well, it is a bit difficult because of the way the equation-based systems > are solved numerically but it might work. > > If you wish to change a model variable you can use daeModel.ON_CONDITION > function (have a look on tutorials 5, 14). If iT is a model variable, you > can put the following in the function DeclareEquations: > > self.ON_CONDITION(Time() > iT, switchToStates = [], > setVariableValues = [iT, iT+1], # here you > may need to use self.iT() > triggerEvents = [], > userDefinedActions = []) > > But, you need to be careful here: your condition Time() > iT will be > triggered EVERY time step once the simulation time becomes greater than iT. > However, you change it each time the condition is satisfied, so it might > work. Please check and let me know, I am curious if it works or not. > > Cheers > Dragan > > > > On 07/03/18 11:45, StUstD wrote: > >> How is it possible to create a discrete-time signal, e.g. a counter (in >> pseudo code): >> >> initial Time = 0 >> iT = 1 # counter >> >> if Time() > iT: >> iT += 1 >> endif >> >> Thanks. >> >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> >> _______________________________________________ >> daetools-users mailing list >> dae...@li... >> https://lists.sourceforge.net/lists/listinfo/daetools-users >> > > |
|
From: StUstD <st...@gm...> - 2018-03-07 14:05:23
|
Thanks, I'm going to give it a try in a simple test environment. Let you know the results. - Henk On Wed, Mar 7, 2018 at 2:49 PM, Dragan Nikolic <dra...@gm...> wrote: > Hi, > > Well, it is a bit difficult because of the way the equation-based systems > are solved numerically but it might work. > > If you wish to change a model variable you can use daeModel.ON_CONDITION > function (have a look on tutorials 5, 14). If iT is a model variable, you > can put the following in the function DeclareEquations: > > self.ON_CONDITION(Time() > iT, switchToStates = [], > setVariableValues = [iT, iT+1], # here you > may need to use self.iT() > triggerEvents = [], > userDefinedActions = []) > > But, you need to be careful here: your condition Time() > iT will be > triggered EVERY time step once the simulation time becomes greater than iT. > However, you change it each time the condition is satisfied, so it might > work. Please check and let me know, I am curious if it works or not. > > Cheers > Dragan > > > > On 07/03/18 11:45, StUstD wrote: > >> How is it possible to create a discrete-time signal, e.g. a counter (in >> pseudo code): >> >> initial Time = 0 >> iT = 1 # counter >> >> if Time() > iT: >> iT += 1 >> endif >> >> Thanks. >> >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> >> _______________________________________________ >> daetools-users mailing list >> dae...@li... >> https://lists.sourceforge.net/lists/listinfo/daetools-users >> > > |
|
From: Dragan N. <dra...@gm...> - 2018-03-07 13:49:46
|
Hi,
Well, it is a bit difficult because of the way the equation-based
systems are solved numerically but it might work.
If you wish to change a model variable you can use daeModel.ON_CONDITION
function (have a look on tutorials 5, 14). If iT is a model variable,
you can put the following in the function DeclareEquations:
self.ON_CONDITION(Time() > iT, switchToStates = [],
setVariableValues = [iT, iT+1], # here
you may need to use self.iT()
triggerEvents = [],
userDefinedActions = [])
But, you need to be careful here: your condition Time() > iT will be
triggered EVERY time step once the simulation time becomes greater than
iT. However, you change it each time the condition is satisfied, so it
might work. Please check and let me know, I am curious if it works or not.
Cheers
Dragan
On 07/03/18 11:45, StUstD wrote:
> How is it possible to create a discrete-time signal, e.g. a counter
> (in pseudo code):
>
> initial Time = 0
> iT = 1 # counter
>
> if Time() > iT:
> iT += 1
> endif
>
> Thanks.
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> daetools-users mailing list
> dae...@li...
> https://lists.sourceforge.net/lists/listinfo/daetools-users
|
|
From: StUstD <st...@gm...> - 2018-03-07 10:45:29
|
How is it possible to create a discrete-time signal, e.g. a counter (in pseudo code): initial Time = 0 iT = 1 # counter if Time() > iT: iT += 1 endif Thanks. |
|
From: Dragan N. <dra...@gm...> - 2017-06-27 14:20:31
|
Hello,
You are always welcome.
Yes, since it can't find the library that surely exists, something is
wrong: either the path to the library or the library name. In this case
it was the library path..
Dragan
On 27/06/17 15:45, Raymond Smith wrote:
> Oh, subtle. Yes, sure enough, that line in CMakeCache.txt has this
> line for me:
> CMAKE_INSTALL_LIBDIR:PATH=lib64
>
> And when I add that line to compile_libraries.sh and recompile with
> those commands, the compile/build runs fine, and I can run
> simulations. Very nice.
>
> Thanks!
> Ray
>
> On Tue, Jun 27, 2017 at 1:36 AM, Dragan Nikolic <dra...@gm...
> <mailto:dra...@gm...>> wrote:
>
> Hi,
>
> No problem. I found what is the error. This is from the build output:
>
> ...
> [100%] Linking C static library libsuperlu.a
> [100%] Built target superlu
> Install the project...
> -- Install configuration: "RELEASE"
> -- Installing:
> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/superlu/build/./lib64/libsuperlu.a
> ...
>
> It seems that in your system superlu automake chose to install the
> compiled libsuperlu.a library to build/lib64 and not build/lib
> folder. That's why the daetools build script cannot find it. I
> haven't seen that before. SuperLU developers switched to cmake so
> did I, too. I need to find why and to fix it in a generic way. I
> have Arch Linux virtual machine but it does not want to upgrade to
> the latest (honestly, it is 2 years old installation). In the
> meantime please go to the trunk/superlu/build folder and find
> CMAKE_INSTALL_LIBDIR in CMakeCache.txt (line 107 in my file):
>
> ...
> //No help, variable specified on the command line.
> CMAKE_INSTALL_LIBDIR:PATH=lib
> ...
>
> In my systems it is lib. Perhaps it is lib64 in your installation?
> Before I commit the update, let's test first. If it is lib64 try
> adding -DCMAKE_INSTALL_LIBDIR:PATH=lib to compile_libraries.sh
> line 1242:
>
> cmake \
> -G"${CMAKE_GENERATOR}" \
> -DCMAKE_BUILD_TYPE:STRING=RELEASE \
> -DBUILD_SHARED_LIBS:BOOL=OFF \
> -DCMAKE_INSTALL_PREFIX:PATH=. \
> *-DCMAKE_INSTALL_LIBDIR:PATH=lib \*
> ...
>
> and recompile only superlu:
>
> sh compile_libraries.sh superlu
> and
> sh compile.sh superlu
>
> Cheers
> Dragan
>
>
> On 27/06/17 05:27, Raymond Smith wrote:
>> Classic. Thanks for the help.
>>
>> That got me quite a bit farther, but I run into something else
>> later. The project seems to compile the libraries okay (I didn't
>> quickly see any glaring errors):
>> https://gist.github.com/anonymous/a300a4bccd01aecb918722d6f6a62f69
>> <https://gist.github.com/anonymous/a300a4bccd01aecb918722d6f6a62f69>
>> but the build step seems to fail not being able to find superLU:
>> https://gist.github.com/anonymous/eca131a83ef624043202245777bcce28
>> <https://gist.github.com/anonymous/eca131a83ef624043202245777bcce28>
>>
>> And then from a python prompt
>> >>> import daetools
>> >>> import daetools.pyDAE as dae
>> work fine. But trying to run a simulation unsurprisingly leads to
>> Traceback (most recent call last):
>> File
>> "/home/raymond/docs/bazantgroup/mpetwork/mpet//bin/mpetrun.py",
>> line 5, in <module>
>> import mpet.main as main
>> File
>> "/home/raymond/docs/bazantgroup/mpetwork/mpet/mpet/main.py", line
>> 11, in <module>
>> from daetools.solvers.superlu import pySuperLU
>> File
>> "/usr/lib/python3.6/site-packages/daetools/solvers/superlu.py",
>> line 20, in <module>
>> import pySuperLU
>> ModuleNotFoundError: No module named 'pySuperLU'
>>
>> Thoughts? If this is too much of a hassle, I can boot up the
>> Debian VM and compile there using more normal compilers, etc.
>>
>> Best,
>> Ray
>>
>> On Mon, Jun 26, 2017 at 2:20 AM, Dragan Nikolic
>> <dra...@gm... <mailto:dra...@gm...>> wrote:
>>
>> Hi again,
>>
>> I found what's causing it (the fmt library in coolprop). As
>> usual, it happens when people try to reinvent a wheel :-)
>>
>> That line (1890) in coolprop/externals/cppformat/fmt/format.h:
>>
>> const unsigned CHAR_WIDTH = 1;
>>
>> defines CHAR_WIDTH which is already defined as a macro in
>> <limits.h> (I checked, the new gcc 7.1 added it, I do not
>> have it in older versions).
>>
>> I added a fix to the compile_libraries.sh build script. It
>> works for me, please check - perhaps something else pops out.
>>
>> Cheers
>> Dragan
>>
>> PS By the way, what's new with you? Did you get a new
>> position or you are still at MIT?
>>
>>
>> On 26/06/17 01:55, Raymond Smith wrote:
>>
>> Hi.
>>
>> I am trying to compile the project, and I got an error on
>> the coolprop library compile, but I don't need that
>> package, so I thought I'd just skip it:
>>
>> $ sh compile_libraries.sh boost ref_blas_lapack umfpack
>> idas superlu superlu_mt bonmin nlopt trilinos deal.ii
>>
>> $ sh compile.sh all
>>
>> However, I got a different error related to the fact that
>> coolprop wasn't compiled in the second step:
>> make[1]: Entering directory
>> '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/pyCore'
>> compiling dllmain.cpp
>> compiling stdafx.cpp
>> compiling dae_python.cpp
>> compiling python_wraps.cpp
>> rm -f libpyCore.so.1.7.0 libpyCore.so libpyCore.so.1
>> libpyCore.so.1.7
>> linking ../release/libpyCore.so.1.7.0
>> /usr/bin/ld: cannot find -lCoolProp
>> collect2: error: ld returned 1 exit status
>> make[1]: *** [Makefile:253:
>> ../release/libpyCore.so.1.7.0] Error 1
>> make[1]: Leaving directory
>> '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/pyCore'
>> make: *** [Makefile:360: sub-pyCore-make_first-ordered]
>> Error 2
>> make: Leaving directory
>> '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk'
>>
>> And for reference, the error from the coolprop compile:
>> [ 22%] Building CXX object
>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/Fluids/FluidLibrary.cpp.o
>> [ 24%] Building CXX object
>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/HelmholtzEOSBackend.cpp.o
>> [ 26%] Building CXX object
>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/HelmholtzEOSMixtureBackend.cpp.o
>> [ 28%] Building CXX object
>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o
>> In file included from
>> /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/limits.h:194:0,
>> from
>> /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/syslimits.h:7,
>> from
>> /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/limits.h:34,
>> from /usr/include/c++/7.1.1/climits:42,
>> from
>> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/Eigen/Eigen/Core:251,
>> from
>> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Helmholtz/MixtureDerivatives.h:17,
>> from
>> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Helmholtz/MixtureDerivatives.cpp:1:
>> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/cppformat/fmt/format.h:
>> In member function ‘void
>> fmt::internal::ArgFormatterBase<Impl,
>> Char>::visit_char(int)’:
>> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/cppformat/fmt/format.h:1890:20:
>> error: expected unqualified-id before numeric constant
>> const unsigned CHAR_WIDTH = 1;
>> ^
>> [ 31%] Building CXX object
>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureParameters.cpp.o
>> make[2]: *** [CMakeFiles/CoolProp.dir/build.make:351:
>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o]
>> Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> make[1]: *** [CMakeFiles/Makefile2:100:
>> CMakeFiles/CoolProp.dir/all] Error 2
>> make: *** [Makefile:130: all] Error 2
>>
>> I'm happy to provide more output if it may be helpful.
>>
>> I'm using svn r725 (corresponding to 1.7.0) on Linux
>> using gcc 7.1.1 glibc 2.25, python 3.6.1, numpy 1.13. I
>> realize those are more recent than those used in the
>> 'official' build based on the sourceforge release page,
>> so it may be related, especially to the compiler error
>> when trying to build coolprop. That's why I was hoping to
>> simply skip that one. Is there a way to build daetools
>> without it at this point? (or an easy way to get around
>> the coolprop compile error?)
>>
>> Thanks,
>> Ray
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the
>> world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>> _______________________________________________
>> daetools-users mailing list
>> dae...@li...
>> <mailto:dae...@li...>
>> https://lists.sourceforge.net/lists/listinfo/daetools-users
>> <https://lists.sourceforge.net/lists/listinfo/daetools-users>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> daetools-users mailing list
>> dae...@li...
>> <mailto:dae...@li...>
>> https://lists.sourceforge.net/lists/listinfo/daetools-users
>> <https://lists.sourceforge.net/lists/listinfo/daetools-users>
>>
>>
>
>
|
|
From: Raymond S. <ray...@gm...> - 2017-06-27 13:45:59
|
Oh, subtle. Yes, sure enough, that line in CMakeCache.txt has this line for
me:
CMAKE_INSTALL_LIBDIR:PATH=lib64
And when I add that line to compile_libraries.sh and recompile with those
commands, the compile/build runs fine, and I can run simulations. Very nice.
Thanks!
Ray
On Tue, Jun 27, 2017 at 1:36 AM, Dragan Nikolic <dra...@gm...>
wrote:
> Hi,
>
> No problem. I found what is the error. This is from the build output:
>
> ...
> [100%] Linking C static library libsuperlu.a
> [100%] Built target superlu
> Install the project...
> -- Install configuration: "RELEASE"
> -- Installing: /home/raymond/builds/mine_python-daetools-svn/20170625/
> src/trunk/superlu/build/./lib64/libsuperlu.a
> ...
>
> It seems that in your system superlu automake chose to install the
> compiled libsuperlu.a library to build/lib64 and not build/lib folder.
> That's why the daetools build script cannot find it. I haven't seen that
> before. SuperLU developers switched to cmake so did I, too. I need to find
> why and to fix it in a generic way. I have Arch Linux virtual machine but
> it does not want to upgrade to the latest (honestly, it is 2 years old
> installation). In the meantime please go to the trunk/superlu/build folder
> and find CMAKE_INSTALL_LIBDIR in CMakeCache.txt (line 107 in my file):
>
> ...
> //No help, variable specified on the command line.
> CMAKE_INSTALL_LIBDIR:PATH=lib
> ...
>
> In my systems it is lib. Perhaps it is lib64 in your installation? Before
> I commit the update, let's test first. If it is lib64 try adding
> -DCMAKE_INSTALL_LIBDIR:PATH=lib to compile_libraries.sh line 1242:
>
> cmake \
> -G"${CMAKE_GENERATOR}" \
> -DCMAKE_BUILD_TYPE:STRING=RELEASE \
> -DBUILD_SHARED_LIBS:BOOL=OFF \
> -DCMAKE_INSTALL_PREFIX:PATH=. \
> *-DCMAKE_INSTALL_LIBDIR:PATH=lib \*
> ...
>
> and recompile only superlu:
>
> sh compile_libraries.sh superlu
> and
> sh compile.sh superlu
>
> Cheers
> Dragan
>
>
> On 27/06/17 05:27, Raymond Smith wrote:
>
> Classic. Thanks for the help.
>
> That got me quite a bit farther, but I run into something else later. The
> project seems to compile the libraries okay (I didn't quickly see any
> glaring errors):
> https://gist.github.com/anonymous/a300a4bccd01aecb918722d6f6a62f69
> but the build step seems to fail not being able to find superLU:
> https://gist.github.com/anonymous/eca131a83ef624043202245777bcce28
>
> And then from a python prompt
> >>> import daetools
> >>> import daetools.pyDAE as dae
> work fine. But trying to run a simulation unsurprisingly leads to
> Traceback (most recent call last):
> File "/home/raymond/docs/bazantgroup/mpetwork/mpet//bin/mpetrun.py",
> line 5, in <module>
> import mpet.main as main
> File "/home/raymond/docs/bazantgroup/mpetwork/mpet/mpet/main.py", line
> 11, in <module>
> from daetools.solvers.superlu import pySuperLU
> File "/usr/lib/python3.6/site-packages/daetools/solvers/superlu.py",
> line 20, in <module>
> import pySuperLU
> ModuleNotFoundError: No module named 'pySuperLU'
>
> Thoughts? If this is too much of a hassle, I can boot up the Debian VM and
> compile there using more normal compilers, etc.
>
> Best,
> Ray
>
> On Mon, Jun 26, 2017 at 2:20 AM, Dragan Nikolic <dra...@gm...>
> wrote:
>
>> Hi again,
>>
>> I found what's causing it (the fmt library in coolprop). As usual, it
>> happens when people try to reinvent a wheel :-)
>>
>> That line (1890) in coolprop/externals/cppformat/fmt/format.h:
>>
>> const unsigned CHAR_WIDTH = 1;
>>
>> defines CHAR_WIDTH which is already defined as a macro in <limits.h> (I
>> checked, the new gcc 7.1 added it, I do not have it in older versions).
>>
>> I added a fix to the compile_libraries.sh build script. It works for me,
>> please check - perhaps something else pops out.
>>
>> Cheers
>> Dragan
>>
>> PS By the way, what's new with you? Did you get a new position or you are
>> still at MIT?
>>
>>
>> On 26/06/17 01:55, Raymond Smith wrote:
>>
>>> Hi.
>>>
>>> I am trying to compile the project, and I got an error on the coolprop
>>> library compile, but I don't need that package, so I thought I'd just skip
>>> it:
>>>
>>> $ sh compile_libraries.sh boost ref_blas_lapack umfpack idas superlu
>>> superlu_mt bonmin nlopt trilinos deal.ii
>>>
>>> $ sh compile.sh all
>>>
>>> However, I got a different error related to the fact that coolprop
>>> wasn't compiled in the second step:
>>> make[1]: Entering directory '/home/raymond/builds/mine_pyt
>>> hon-daetools-svn/20170625/src/trunk/pyCore'
>>> compiling dllmain.cpp
>>> compiling stdafx.cpp
>>> compiling dae_python.cpp
>>> compiling python_wraps.cpp
>>> rm -f libpyCore.so.1.7.0 libpyCore.so libpyCore.so.1 libpyCore.so.1.7
>>> linking ../release/libpyCore.so.1.7.0
>>> /usr/bin/ld: cannot find -lCoolProp
>>> collect2: error: ld returned 1 exit status
>>> make[1]: *** [Makefile:253: ../release/libpyCore.so.1.7.0] Error 1
>>> make[1]: Leaving directory '/home/raymond/builds/mine_pyt
>>> hon-daetools-svn/20170625/src/trunk/pyCore'
>>> make: *** [Makefile:360: sub-pyCore-make_first-ordered] Error 2
>>> make: Leaving directory '/home/raymond/builds/mine_pyt
>>> hon-daetools-svn/20170625/src/trunk'
>>>
>>> And for reference, the error from the coolprop compile:
>>> [ 22%] Building CXX object CMakeFiles/CoolProp.dir/src/Ba
>>> ckends/Helmholtz/Fluids/FluidLibrary.cpp.o
>>> [ 24%] Building CXX object CMakeFiles/CoolProp.dir/src/Ba
>>> ckends/Helmholtz/HelmholtzEOSBackend.cpp.o
>>> [ 26%] Building CXX object CMakeFiles/CoolProp.dir/src/Ba
>>> ckends/Helmholtz/HelmholtzEOSMixtureBackend.cpp.o
>>> [ 28%] Building CXX object CMakeFiles/CoolProp.dir/src/Ba
>>> ckends/Helmholtz/MixtureDerivatives.cpp.o
>>> In file included from /usr/lib/gcc/x86_64-pc-linux-g
>>> nu/7.1.1/include-fixed/limits.h:194:0,
>>> from /usr/lib/gcc/x86_64-pc-linux-g
>>> nu/7.1.1/include-fixed/syslimits.h:7,
>>> from /usr/lib/gcc/x86_64-pc-linux-g
>>> nu/7.1.1/include-fixed/limits.h:34,
>>> from /usr/include/c++/7.1.1/climits:42,
>>> from /home/raymond/builds/mine_pyth
>>> on-daetools-svn/20170625/src/trunk/coolprop/externals/Eigen/
>>> Eigen/Core:251,
>>> from /home/raymond/builds/mine_pyth
>>> on-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Hel
>>> mholtz/MixtureDerivatives.h:17,
>>> from /home/raymond/builds/mine_pyth
>>> on-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Hel
>>> mholtz/MixtureDerivatives.cpp:1:
>>> /home/raymond/builds/mine_python-daetools-svn/20170625/src/t
>>> runk/coolprop/externals/cppformat/fmt/format.h: In member function
>>> ‘void fmt::internal::ArgFormatterBase<Impl, Char>::visit_char(int)’:
>>> /home/raymond/builds/mine_python-daetools-svn/20170625/src/t
>>> runk/coolprop/externals/cppformat/fmt/format.h:1890:20: error: expected
>>> unqualified-id before numeric constant
>>> const unsigned CHAR_WIDTH = 1;
>>> ^
>>> [ 31%] Building CXX object CMakeFiles/CoolProp.dir/src/Ba
>>> ckends/Helmholtz/MixtureParameters.cpp.o
>>> make[2]: *** [CMakeFiles/CoolProp.dir/build.make:351:
>>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o]
>>> Error 1
>>> make[2]: *** Waiting for unfinished jobs....
>>> make[1]: *** [CMakeFiles/Makefile2:100: CMakeFiles/CoolProp.dir/all]
>>> Error 2
>>> make: *** [Makefile:130: all] Error 2
>>>
>>> I'm happy to provide more output if it may be helpful.
>>>
>>> I'm using svn r725 (corresponding to 1.7.0) on Linux using gcc 7.1.1
>>> glibc 2.25, python 3.6.1, numpy 1.13. I realize those are more recent than
>>> those used in the 'official' build based on the sourceforge release page,
>>> so it may be related, especially to the compiler error when trying to build
>>> coolprop. That's why I was hoping to simply skip that one. Is there a way
>>> to build daetools without it at this point? (or an easy way to get around
>>> the coolprop compile error?)
>>>
>>> Thanks,
>>> Ray
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>
>>>
>>> _______________________________________________
>>> daetools-users mailing list
>>> dae...@li...
>>> https://lists.sourceforge.net/lists/listinfo/daetools-users
>>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> daetools-users mailing list
>> dae...@li...
>> https://lists.sourceforge.net/lists/listinfo/daetools-users
>>
>
>
>
|
|
From: Dragan N. <dra...@gm...> - 2017-06-27 08:37:06
|
Hi,
No problem. I found what is the error. This is from the build output:
...
[100%] Linking C static library libsuperlu.a
[100%] Built target superlu
Install the project...
-- Install configuration: "RELEASE"
-- Installing:
/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/superlu/build/./lib64/libsuperlu.a
...
It seems that in your system superlu automake chose to install the
compiled libsuperlu.a library to build/lib64 and not build/lib folder.
That's why the daetools build script cannot find it. I haven't seen that
before. SuperLU developers switched to cmake so did I, too. I need to
find why and to fix it in a generic way. I have Arch Linux virtual
machine but it does not want to upgrade to the latest (honestly, it is 2
years old installation). In the meantime please go to the
trunk/superlu/build folder and find CMAKE_INSTALL_LIBDIR in
CMakeCache.txt (line 107 in my file):
...
//No help, variable specified on the command line.
CMAKE_INSTALL_LIBDIR:PATH=lib
...
In my systems it is lib. Perhaps it is lib64 in your installation?
Before I commit the update, let's test first. If it is lib64 try adding
-DCMAKE_INSTALL_LIBDIR:PATH=lib to compile_libraries.sh line 1242:
cmake \
-G"${CMAKE_GENERATOR}" \
-DCMAKE_BUILD_TYPE:STRING=RELEASE \
-DBUILD_SHARED_LIBS:BOOL=OFF \
-DCMAKE_INSTALL_PREFIX:PATH=. \
*-DCMAKE_INSTALL_LIBDIR:PATH=lib \*
...
and recompile only superlu:
sh compile_libraries.sh superlu
and
sh compile.sh superlu
Cheers
Dragan
On 27/06/17 05:27, Raymond Smith wrote:
> Classic. Thanks for the help.
>
> That got me quite a bit farther, but I run into something else later.
> The project seems to compile the libraries okay (I didn't quickly see
> any glaring errors):
> https://gist.github.com/anonymous/a300a4bccd01aecb918722d6f6a62f69
> <https://gist.github.com/anonymous/a300a4bccd01aecb918722d6f6a62f69>
> but the build step seems to fail not being able to find superLU:
> https://gist.github.com/anonymous/eca131a83ef624043202245777bcce28
> <https://gist.github.com/anonymous/eca131a83ef624043202245777bcce28>
>
> And then from a python prompt
> >>> import daetools
> >>> import daetools.pyDAE as dae
> work fine. But trying to run a simulation unsurprisingly leads to
> Traceback (most recent call last):
> File "/home/raymond/docs/bazantgroup/mpetwork/mpet//bin/mpetrun.py",
> line 5, in <module>
> import mpet.main as main
> File "/home/raymond/docs/bazantgroup/mpetwork/mpet/mpet/main.py",
> line 11, in <module>
> from daetools.solvers.superlu import pySuperLU
> File "/usr/lib/python3.6/site-packages/daetools/solvers/superlu.py",
> line 20, in <module>
> import pySuperLU
> ModuleNotFoundError: No module named 'pySuperLU'
>
> Thoughts? If this is too much of a hassle, I can boot up the Debian VM
> and compile there using more normal compilers, etc.
>
> Best,
> Ray
>
> On Mon, Jun 26, 2017 at 2:20 AM, Dragan Nikolic <dra...@gm...
> <mailto:dra...@gm...>> wrote:
>
> Hi again,
>
> I found what's causing it (the fmt library in coolprop). As usual,
> it happens when people try to reinvent a wheel :-)
>
> That line (1890) in coolprop/externals/cppformat/fmt/format.h:
>
> const unsigned CHAR_WIDTH = 1;
>
> defines CHAR_WIDTH which is already defined as a macro in
> <limits.h> (I checked, the new gcc 7.1 added it, I do not have it
> in older versions).
>
> I added a fix to the compile_libraries.sh build script. It works
> for me, please check - perhaps something else pops out.
>
> Cheers
> Dragan
>
> PS By the way, what's new with you? Did you get a new position or
> you are still at MIT?
>
>
> On 26/06/17 01:55, Raymond Smith wrote:
>
> Hi.
>
> I am trying to compile the project, and I got an error on the
> coolprop library compile, but I don't need that package, so I
> thought I'd just skip it:
>
> $ sh compile_libraries.sh boost ref_blas_lapack umfpack idas
> superlu superlu_mt bonmin nlopt trilinos deal.ii
>
> $ sh compile.sh all
>
> However, I got a different error related to the fact that
> coolprop wasn't compiled in the second step:
> make[1]: Entering directory
> '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/pyCore'
> compiling dllmain.cpp
> compiling stdafx.cpp
> compiling dae_python.cpp
> compiling python_wraps.cpp
> rm -f libpyCore.so.1.7.0 libpyCore.so libpyCore.so.1
> libpyCore.so.1.7
> linking ../release/libpyCore.so.1.7.0
> /usr/bin/ld: cannot find -lCoolProp
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:253: ../release/libpyCore.so.1.7.0] Error 1
> make[1]: Leaving directory
> '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/pyCore'
> make: *** [Makefile:360: sub-pyCore-make_first-ordered] Error 2
> make: Leaving directory
> '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk'
>
> And for reference, the error from the coolprop compile:
> [ 22%] Building CXX object
> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/Fluids/FluidLibrary.cpp.o
> [ 24%] Building CXX object
> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/HelmholtzEOSBackend.cpp.o
> [ 26%] Building CXX object
> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/HelmholtzEOSMixtureBackend.cpp.o
> [ 28%] Building CXX object
> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o
> In file included from
> /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/limits.h:194:0,
> from
> /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/syslimits.h:7,
> from
> /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/limits.h:34,
> from /usr/include/c++/7.1.1/climits:42,
> from
> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/Eigen/Eigen/Core:251,
> from
> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Helmholtz/MixtureDerivatives.h:17,
> from
> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Helmholtz/MixtureDerivatives.cpp:1:
> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/cppformat/fmt/format.h:
> In member function ‘void fmt::internal::ArgFormatterBase<Impl,
> Char>::visit_char(int)’:
> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/cppformat/fmt/format.h:1890:20:
> error: expected unqualified-id before numeric constant
> const unsigned CHAR_WIDTH = 1;
> ^
> [ 31%] Building CXX object
> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureParameters.cpp.o
> make[2]: *** [CMakeFiles/CoolProp.dir/build.make:351:
> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o]
> Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [CMakeFiles/Makefile2:100:
> CMakeFiles/CoolProp.dir/all] Error 2
> make: *** [Makefile:130: all] Error 2
>
> I'm happy to provide more output if it may be helpful.
>
> I'm using svn r725 (corresponding to 1.7.0) on Linux using gcc
> 7.1.1 glibc 2.25, python 3.6.1, numpy 1.13. I realize those
> are more recent than those used in the 'official' build based
> on the sourceforge release page, so it may be related,
> especially to the compiler error when trying to build
> coolprop. That's why I was hoping to simply skip that one. Is
> there a way to build daetools without it at this point? (or an
> easy way to get around the coolprop compile error?)
>
> Thanks,
> Ray
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> daetools-users mailing list
> dae...@li...
> <mailto:dae...@li...>
> https://lists.sourceforge.net/lists/listinfo/daetools-users
> <https://lists.sourceforge.net/lists/listinfo/daetools-users>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> daetools-users mailing list
> dae...@li...
> <mailto:dae...@li...>
> https://lists.sourceforge.net/lists/listinfo/daetools-users
> <https://lists.sourceforge.net/lists/listinfo/daetools-users>
>
>
|
|
From: Raymond S. <ray...@gm...> - 2017-06-27 03:27:53
|
Classic. Thanks for the help. That got me quite a bit farther, but I run into something else later. The project seems to compile the libraries okay (I didn't quickly see any glaring errors): https://gist.github.com/anonymous/a300a4bccd01aecb918722d6f6a62f69 but the build step seems to fail not being able to find superLU: https://gist.github.com/anonymous/eca131a83ef624043202245777bcce28 And then from a python prompt >>> import daetools >>> import daetools.pyDAE as dae work fine. But trying to run a simulation unsurprisingly leads to Traceback (most recent call last): File "/home/raymond/docs/bazantgroup/mpetwork/mpet//bin/mpetrun.py", line 5, in <module> import mpet.main as main File "/home/raymond/docs/bazantgroup/mpetwork/mpet/mpet/main.py", line 11, in <module> from daetools.solvers.superlu import pySuperLU File "/usr/lib/python3.6/site-packages/daetools/solvers/superlu.py", line 20, in <module> import pySuperLU ModuleNotFoundError: No module named 'pySuperLU' Thoughts? If this is too much of a hassle, I can boot up the Debian VM and compile there using more normal compilers, etc. Best, Ray On Mon, Jun 26, 2017 at 2:20 AM, Dragan Nikolic <dra...@gm...> wrote: > Hi again, > > I found what's causing it (the fmt library in coolprop). As usual, it > happens when people try to reinvent a wheel :-) > > That line (1890) in coolprop/externals/cppformat/fmt/format.h: > > const unsigned CHAR_WIDTH = 1; > > defines CHAR_WIDTH which is already defined as a macro in <limits.h> (I > checked, the new gcc 7.1 added it, I do not have it in older versions). > > I added a fix to the compile_libraries.sh build script. It works for me, > please check - perhaps something else pops out. > > Cheers > Dragan > > PS By the way, what's new with you? Did you get a new position or you are > still at MIT? > > > On 26/06/17 01:55, Raymond Smith wrote: > >> Hi. >> >> I am trying to compile the project, and I got an error on the coolprop >> library compile, but I don't need that package, so I thought I'd just skip >> it: >> >> $ sh compile_libraries.sh boost ref_blas_lapack umfpack idas superlu >> superlu_mt bonmin nlopt trilinos deal.ii >> >> $ sh compile.sh all >> >> However, I got a different error related to the fact that coolprop wasn't >> compiled in the second step: >> make[1]: Entering directory '/home/raymond/builds/mine_pyt >> hon-daetools-svn/20170625/src/trunk/pyCore' >> compiling dllmain.cpp >> compiling stdafx.cpp >> compiling dae_python.cpp >> compiling python_wraps.cpp >> rm -f libpyCore.so.1.7.0 libpyCore.so libpyCore.so.1 libpyCore.so.1.7 >> linking ../release/libpyCore.so.1.7.0 >> /usr/bin/ld: cannot find -lCoolProp >> collect2: error: ld returned 1 exit status >> make[1]: *** [Makefile:253: ../release/libpyCore.so.1.7.0] Error 1 >> make[1]: Leaving directory '/home/raymond/builds/mine_pyt >> hon-daetools-svn/20170625/src/trunk/pyCore' >> make: *** [Makefile:360: sub-pyCore-make_first-ordered] Error 2 >> make: Leaving directory '/home/raymond/builds/mine_pyt >> hon-daetools-svn/20170625/src/trunk' >> >> And for reference, the error from the coolprop compile: >> [ 22%] Building CXX object CMakeFiles/CoolProp.dir/src/Ba >> ckends/Helmholtz/Fluids/FluidLibrary.cpp.o >> [ 24%] Building CXX object CMakeFiles/CoolProp.dir/src/Ba >> ckends/Helmholtz/HelmholtzEOSBackend.cpp.o >> [ 26%] Building CXX object CMakeFiles/CoolProp.dir/src/Ba >> ckends/Helmholtz/HelmholtzEOSMixtureBackend.cpp.o >> [ 28%] Building CXX object CMakeFiles/CoolProp.dir/src/Ba >> ckends/Helmholtz/MixtureDerivatives.cpp.o >> In file included from /usr/lib/gcc/x86_64-pc-linux-g >> nu/7.1.1/include-fixed/limits.h:194:0, >> from /usr/lib/gcc/x86_64-pc-linux-g >> nu/7.1.1/include-fixed/syslimits.h:7, >> from /usr/lib/gcc/x86_64-pc-linux-g >> nu/7.1.1/include-fixed/limits.h:34, >> from /usr/include/c++/7.1.1/climits:42, >> from /home/raymond/builds/mine_pyth >> on-daetools-svn/20170625/src/trunk/coolprop/externals/Eigen/ >> Eigen/Core:251, >> from /home/raymond/builds/mine_pyth >> on-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Hel >> mholtz/MixtureDerivatives.h:17, >> from /home/raymond/builds/mine_pyth >> on-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Hel >> mholtz/MixtureDerivatives.cpp:1: >> /home/raymond/builds/mine_python-daetools-svn/20170625/src/t >> runk/coolprop/externals/cppformat/fmt/format.h: In member function ‘void >> fmt::internal::ArgFormatterBase<Impl, Char>::visit_char(int)’: >> /home/raymond/builds/mine_python-daetools-svn/20170625/src/t >> runk/coolprop/externals/cppformat/fmt/format.h:1890:20: error: expected >> unqualified-id before numeric constant >> const unsigned CHAR_WIDTH = 1; >> ^ >> [ 31%] Building CXX object CMakeFiles/CoolProp.dir/src/Ba >> ckends/Helmholtz/MixtureParameters.cpp.o >> make[2]: *** [CMakeFiles/CoolProp.dir/build.make:351: >> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o] >> Error 1 >> make[2]: *** Waiting for unfinished jobs.... >> make[1]: *** [CMakeFiles/Makefile2:100: CMakeFiles/CoolProp.dir/all] >> Error 2 >> make: *** [Makefile:130: all] Error 2 >> >> I'm happy to provide more output if it may be helpful. >> >> I'm using svn r725 (corresponding to 1.7.0) on Linux using gcc 7.1.1 >> glibc 2.25, python 3.6.1, numpy 1.13. I realize those are more recent than >> those used in the 'official' build based on the sourceforge release page, >> so it may be related, especially to the compiler error when trying to build >> coolprop. That's why I was hoping to simply skip that one. Is there a way >> to build daetools without it at this point? (or an easy way to get around >> the coolprop compile error?) >> >> Thanks, >> Ray >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> >> _______________________________________________ >> daetools-users mailing list >> dae...@li... >> https://lists.sourceforge.net/lists/listinfo/daetools-users >> > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > daetools-users mailing list > dae...@li... > https://lists.sourceforge.net/lists/listinfo/daetools-users > |
|
From: Dragan N. <dra...@gm...> - 2017-06-26 09:21:01
|
Hi again, I found what's causing it (the fmt library in coolprop). As usual, it happens when people try to reinvent a wheel :-) That line (1890) in coolprop/externals/cppformat/fmt/format.h: const unsigned CHAR_WIDTH = 1; defines CHAR_WIDTH which is already defined as a macro in <limits.h> (I checked, the new gcc 7.1 added it, I do not have it in older versions). I added a fix to the compile_libraries.sh build script. It works for me, please check - perhaps something else pops out. Cheers Dragan PS By the way, what's new with you? Did you get a new position or you are still at MIT? On 26/06/17 01:55, Raymond Smith wrote: > Hi. > > I am trying to compile the project, and I got an error on the coolprop > library compile, but I don't need that package, so I thought I'd just > skip it: > > $ sh compile_libraries.sh boost ref_blas_lapack umfpack idas superlu > superlu_mt bonmin nlopt trilinos deal.ii > > $ sh compile.sh all > > However, I got a different error related to the fact that coolprop > wasn't compiled in the second step: > make[1]: Entering directory > '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/pyCore' > compiling dllmain.cpp > compiling stdafx.cpp > compiling dae_python.cpp > compiling python_wraps.cpp > rm -f libpyCore.so.1.7.0 libpyCore.so libpyCore.so.1 libpyCore.so.1.7 > linking ../release/libpyCore.so.1.7.0 > /usr/bin/ld: cannot find -lCoolProp > collect2: error: ld returned 1 exit status > make[1]: *** [Makefile:253: ../release/libpyCore.so.1.7.0] Error 1 > make[1]: Leaving directory > '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/pyCore' > make: *** [Makefile:360: sub-pyCore-make_first-ordered] Error 2 > make: Leaving directory > '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk' > > And for reference, the error from the coolprop compile: > [ 22%] Building CXX object > CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/Fluids/FluidLibrary.cpp.o > [ 24%] Building CXX object > CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/HelmholtzEOSBackend.cpp.o > [ 26%] Building CXX object > CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/HelmholtzEOSMixtureBackend.cpp.o > [ 28%] Building CXX object > CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o > In file included from > /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/limits.h:194:0, > from > /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/syslimits.h:7, > from > /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/limits.h:34, > from /usr/include/c++/7.1.1/climits:42, > from > /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/Eigen/Eigen/Core:251, > from > /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Helmholtz/MixtureDerivatives.h:17, > from > /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Helmholtz/MixtureDerivatives.cpp:1: > /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/cppformat/fmt/format.h: > In member function ‘void fmt::internal::ArgFormatterBase<Impl, > Char>::visit_char(int)’: > /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/cppformat/fmt/format.h:1890:20: > error: expected unqualified-id before numeric constant > const unsigned CHAR_WIDTH = 1; > ^ > [ 31%] Building CXX object > CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureParameters.cpp.o > make[2]: *** [CMakeFiles/CoolProp.dir/build.make:351: > CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o] > Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [CMakeFiles/Makefile2:100: CMakeFiles/CoolProp.dir/all] > Error 2 > make: *** [Makefile:130: all] Error 2 > > I'm happy to provide more output if it may be helpful. > > I'm using svn r725 (corresponding to 1.7.0) on Linux using gcc 7.1.1 > glibc 2.25, python 3.6.1, numpy 1.13. I realize those are more recent > than those used in the 'official' build based on the sourceforge > release page, so it may be related, especially to the compiler error > when trying to build coolprop. That's why I was hoping to simply skip > that one. Is there a way to build daetools without it at this point? > (or an easy way to get around the coolprop compile error?) > > Thanks, > Ray > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > daetools-users mailing list > dae...@li... > https://lists.sourceforge.net/lists/listinfo/daetools-users |
|
From: Dragan N. <dra...@gm...> - 2017-06-26 07:42:57
|
Hey Ray, How are you? Everything fine there? I'll check what is going on, I think I had problems with compilation at the beginning (4.9 or 6.3, can't recall exactly). Yes, coolprop is required for daetools. I can do two things: a) make it compile cleanly and b) make it an additional (optional) module. At this point better to try to fix it. I exchanged few times to Michael Forsuelo from your group. We fixed calculation of sensitivities and I am adding the global sensitivity analysis at the moment. Can your models benefit from it? It typically reveals the effects of parameters and their dependency and many other useful stuff. I'll get back with the news about coolprop soon. Cheers Dragan On 26/06/17 01:55, Raymond Smith wrote: > Hi. > > I am trying to compile the project, and I got an error on the coolprop > library compile, but I don't need that package, so I thought I'd just > skip it: > > $ sh compile_libraries.sh boost ref_blas_lapack umfpack idas superlu > superlu_mt bonmin nlopt trilinos deal.ii > > $ sh compile.sh all > > However, I got a different error related to the fact that coolprop > wasn't compiled in the second step: > make[1]: Entering directory > '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/pyCore' > compiling dllmain.cpp > compiling stdafx.cpp > compiling dae_python.cpp > compiling python_wraps.cpp > rm -f libpyCore.so.1.7.0 libpyCore.so libpyCore.so.1 libpyCore.so.1.7 > linking ../release/libpyCore.so.1.7.0 > /usr/bin/ld: cannot find -lCoolProp > collect2: error: ld returned 1 exit status > make[1]: *** [Makefile:253: ../release/libpyCore.so.1.7.0] Error 1 > make[1]: Leaving directory > '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/pyCore' > make: *** [Makefile:360: sub-pyCore-make_first-ordered] Error 2 > make: Leaving directory > '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk' > > And for reference, the error from the coolprop compile: > [ 22%] Building CXX object > CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/Fluids/FluidLibrary.cpp.o > [ 24%] Building CXX object > CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/HelmholtzEOSBackend.cpp.o > [ 26%] Building CXX object > CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/HelmholtzEOSMixtureBackend.cpp.o > [ 28%] Building CXX object > CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o > In file included from > /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/limits.h:194:0, > from > /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/syslimits.h:7, > from > /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/limits.h:34, > from /usr/include/c++/7.1.1/climits:42, > from > /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/Eigen/Eigen/Core:251, > from > /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Helmholtz/MixtureDerivatives.h:17, > from > /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Helmholtz/MixtureDerivatives.cpp:1: > /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/cppformat/fmt/format.h: > In member function ‘void fmt::internal::ArgFormatterBase<Impl, > Char>::visit_char(int)’: > /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/cppformat/fmt/format.h:1890:20: > error: expected unqualified-id before numeric constant > const unsigned CHAR_WIDTH = 1; > ^ > [ 31%] Building CXX object > CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureParameters.cpp.o > make[2]: *** [CMakeFiles/CoolProp.dir/build.make:351: > CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o] > Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [CMakeFiles/Makefile2:100: CMakeFiles/CoolProp.dir/all] > Error 2 > make: *** [Makefile:130: all] Error 2 > > I'm happy to provide more output if it may be helpful. > > I'm using svn r725 (corresponding to 1.7.0) on Linux using gcc 7.1.1 > glibc 2.25, python 3.6.1, numpy 1.13. I realize those are more recent > than those used in the 'official' build based on the sourceforge > release page, so it may be related, especially to the compiler error > when trying to build coolprop. That's why I was hoping to simply skip > that one. Is there a way to build daetools without it at this point? > (or an easy way to get around the coolprop compile error?) > > Thanks, > Ray > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > daetools-users mailing list > dae...@li... > https://lists.sourceforge.net/lists/listinfo/daetools-users |
|
From: Raymond S. <ray...@gm...> - 2017-06-25 23:56:37
|
Hi.
I am trying to compile the project, and I got an error on the coolprop
library compile, but I don't need that package, so I thought I'd just skip
it:
$ sh compile_libraries.sh boost ref_blas_lapack umfpack idas superlu
superlu_mt bonmin nlopt trilinos deal.ii
$ sh compile.sh all
However, I got a different error related to the fact that coolprop wasn't
compiled in the second step:
make[1]: Entering directory
'/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/pyCore'
compiling dllmain.cpp
compiling stdafx.cpp
compiling dae_python.cpp
compiling python_wraps.cpp
rm -f libpyCore.so.1.7.0 libpyCore.so libpyCore.so.1 libpyCore.so.1.7
linking ../release/libpyCore.so.1.7.0
/usr/bin/ld: cannot find -lCoolProp
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:253: ../release/libpyCore.so.1.7.0] Error 1
make[1]: Leaving directory
'/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/pyCore'
make: *** [Makefile:360: sub-pyCore-make_first-ordered] Error 2
make: Leaving directory
'/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk'
And for reference, the error from the coolprop compile:
[ 22%] Building CXX object
CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/Fluids/FluidLibrary.cpp.o
[ 24%] Building CXX object
CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/HelmholtzEOSBackend.cpp.o
[ 26%] Building CXX object
CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/HelmholtzEOSMixtureBackend.cpp.o
[ 28%] Building CXX object
CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/limits.h:194:0,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/syslimits.h:7,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/limits.h:34,
from /usr/include/c++/7.1.1/climits:42,
from
/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/Eigen/Eigen/Core:251,
from
/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Helmholtz/MixtureDerivatives.h:17,
from
/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Helmholtz/MixtureDerivatives.cpp:1:
/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/cppformat/fmt/format.h:
In member function ‘void fmt::internal::ArgFormatterBase<Impl,
Char>::visit_char(int)’:
/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/cppformat/fmt/format.h:1890:20:
error: expected unqualified-id before numeric constant
const unsigned CHAR_WIDTH = 1;
^
[ 31%] Building CXX object
CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureParameters.cpp.o
make[2]: *** [CMakeFiles/CoolProp.dir/build.make:351:
CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o]
Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:100: CMakeFiles/CoolProp.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
I'm happy to provide more output if it may be helpful.
I'm using svn r725 (corresponding to 1.7.0) on Linux using gcc 7.1.1 glibc
2.25, python 3.6.1, numpy 1.13. I realize those are more recent than those
used in the 'official' build based on the sourceforge release page, so it
may be related, especially to the compiler error when trying to build
coolprop. That's why I was hoping to simply skip that one. Is there a way
to build daetools without it at this point? (or an easy way to get around
the coolprop compile error?)
Thanks,
Ray
|
|
From: Dragan N. <dra...@gm...> - 2017-06-17 08:45:49
|
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Martin,<br>
<br>
Great, I thought that might be a problem. No problem, you're
welcome.<br>
<br>
Cheers<br>
Dragan<br>
<br>
<div class="moz-cite-prefix">On 17/06/17 00:23, Ebner Martin wrote:<br>
</div>
<blockquote cite="mid:922...@et..."
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div style="margin: 0px; font-size: 11px; line-height: normal;
font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures;" class="">Dear
Dragan,</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal;
font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures;" class=""><br
class="">
</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal;
font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures;" class="">thanks
for the tip, that did the trick!</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal;
font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures;" class=""><br
class="">
</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal;
font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures;" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="">
<div class="" style="margin: 0px; font-size: 11px;
line-height: normal; font-family: Menlo;"><span
class="" style="font-variant-ligatures:
no-common-ligatures;">
<div class="">
<div class="" style="margin: 0px; line-height:
normal;"><span class="" style="color: rgb(102,
156, 53);"># Download HPC-GCC 6.3</span></div>
</div>
<div class="">
<div class="">
<div class="" style="margin: 0px; line-height:
normal;"><span class=""
style="font-variant-ligatures:
no-common-ligatures;">bash-3.2$ </span><font
class="" color="#d357fe">curl -O <a
moz-do-not-send="true"
href="https://freefr.dl.sourceforge.net/project/hpc/hpc/gcc/gcc-6.3-bin.tar.gz"
class="">https://freefr.dl.sourceforge.net/project/hpc/hpc/gcc/gcc-6.3-bin.tar.gz</a></font></div>
</div>
<div class="" style="margin: 0px; line-height:
normal;"><font class="" color="#669c35"># </font><span
style="color: rgb(102, 156, 53);" class="">Install
HPC-GCC 6.3</span></div>
<div class="" style="margin: 0px; line-height:
normal;"><span class=""
style="font-variant-ligatures:
no-common-ligatures;">bash-3.2$ </span><font
class="" color="#d357fe">sudo tar -xvf
gcc-6.3-bin.tar.gz -C /</font></div>
<div class="" style="margin: 0px; line-height:
normal;"><span class=""
style="font-variant-ligatures:
no-common-ligatures;"></span></div>
</div>
</span></div>
</div>
</div>
</div>
</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal;
font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures;" class=""><br
class="">
</span></div>
<div style="margin: 0px; line-height: normal;" class=""><span
style="font-variant-ligatures: no-common-ligatures;" class=""><font
class="" style="font-family: Menlo; font-size: 11px;"
color="#669c35"># </font><font class="" color="#669c35"
face="Menlo"><span style="font-size: 11px;" class="">… code
from below ...</span></font></span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal;
font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures;" class=""><span
style="color: rgb(102, 156, 53);" class=""><br class="">
</span></span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal;
font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures;" class=""><font
class="" color="#669c35"># </font><font style="font-size:
12px;" class="" color="#669c35" face="Menlo"><span
style="font-size: 11px;" class="">Test DAEtools</span></font></span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal;
font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures;" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="" style="margin: 0px; font-size: 11px;
line-height: normal; font-family: Menlo;"><span class=""
style="font-variant-ligatures: no-common-ligatures;">(python3.4)
bash-3.2$ </span><font class="" color="#d357fe">python</font></div>
</div>
</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal;
font-family: Menlo;" class="">
<div style="margin: 0px; line-height: normal;" class=""><span
style="font-variant-ligatures: no-common-ligatures" class="">Python
3.4.5 |Anaconda custom (x86_64)| (default, Jul 2 2016,
17:47:57) </span></div>
<div style="margin: 0px; line-height: normal;" class=""><span
style="font-variant-ligatures: no-common-ligatures" class="">[GCC
4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin</span></div>
<div style="margin: 0px; line-height: normal;" class=""><span
style="font-variant-ligatures: no-common-ligatures" class="">Type
"help", "copyright", "credits" or "license" for more
information.</span></div>
<div style="margin: 0px; line-height: normal;" class=""><span
style="font-variant-ligatures: no-common-ligatures" class="">>>>
<font class="" color="#d357fe">import daetools.pyDAE</font></span></div>
<div style="margin: 0px; line-height: normal;" class=""><span
style="font-variant-ligatures: no-common-ligatures" class="">>>> </span></div>
<div style="margin: 0px; line-height: normal;" class=""><font
class="" color="#669c35"># </font><font style="font-size:
12px;" class="" color="#669c35" face="Menlo"><span
style="font-size: 11px;" class="">ALL IS FINE!</span></font></div>
<div class=""><br class="">
</div>
</div>
<div style="margin: 0px; font-size: 11px; line-height: normal;
font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures;" class="">Cheers,
Martin!</span></div>
<div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap:
break-word; -webkit-nbsp-mode: space; -webkit-line-break:
after-white-space;" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<div class="">—</div>
<div class="">Dr. Martin Ebner<br class="">
Laboratory for Nanoelectronics<br class="">
Dept. of Electrical Engineering and Information
Technology<br class="">
ETH Zürich<br class="">
<br class="">
address:<br class="">
Gloriastrasse 35, ETZ H65<br class="">
Zürich, 8092 Switzerland<br class="">
<br class="">
email: <a moz-do-not-send="true"
href="mailto:me...@et..." class="">me...@et...</a><br
class="">
phone: +41 (0)44-632-46-03<br class="">
web: <a moz-do-not-send="true"
href="http://lne.ethz.ch" class="">lne.ethz.ch</a></div>
</div>
</div>
</div>
</div>
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 17 Jun 2017, at 00:01, Dragan Nikolic <<a
moz-do-not-send="true" href="mailto:dra...@gm..."
class="">dra...@gm...</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div bgcolor="#FFFFFF" text="#000000" class=""> Hey Ebner,<br
class="">
<br class="">
I think it is the std c++ library issue. Good that you use
macOS to test it. I compiled the latest release using the
g++ compiler that is not from XCode - gcc 6.3 from HPC for
Mac website (some libraries won't compile with the clang
or gcc from XCode). The most likely the version of std c++
library that comes with mac by default is much older (I
think they still use gcc 4.4.2 or something like that) so
some symbols are missing. I guess, the quick fix is if you
get and install gcc 6.3 from <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://hpc.sourceforge.net/">http://hpc.sourceforge.net</a>
it will work. It installs libraries in /usr/local/lib
directory I think. Or just copy the <span
style="font-variant-ligatures: no-common-ligatures"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class="">libstdc++.6.dylib to
/usr/local/lib.</span></span> I'll try to fix this
issue in the meantime (perhaps link statically or provide
the std c++ lib with daetools).<br class="">
<br class="">
Cheers<br class="">
Dragan<br class="">
<br class="">
<div class="moz-cite-prefix">On 16/06/17 23:03, Ebner
Martin wrote:<br class="">
</div>
<blockquote
cite="mid:9B1...@et..."
type="cite" class="">
<div class="">
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class=""><font class="">Hi,
i’m trying to use daetools-1.7.0 on macOS 10.11.6
with python 3.4 (although i also tried 2.7,3.5,and
3.6). after installing and calling “import
daetools.pyDAE”, i get an “Symbol not found” error
(see below). I’ve tested the same on a windows
machine and there it works fine. am i missing
something?</font></div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class=""><br class="">
</div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class="">here’s my
approach for a clean installation and what happens
if i call “import daetools.pyDAE”.</div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class=""><br class="">
</div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class="">any idea what
do do?</div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class=""><br class="">
</div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class="">thanks,</div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class="">Martin </div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class=""><span
style="color: rgb(102, 156, 53);" class=""><span
style="" class=""><br class="">
</span></span></div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class=""><span
style="color: rgb(102, 156, 53);" class="">#
Download Miniconda</span></div>
</div>
<div class="">
<div class="">
<div style="margin: 0px; font-size: 11px;
line-height: normal; font-family: Menlo;" class=""><span
style="font-variant-ligatures:
no-common-ligatures;" class="">bash-3.2$ <font
class="" color="#d357fe">curl -O <a
moz-do-not-send="true"
href="https://repo.continuum.io/miniconda/Miniconda3-latest-MacOSX-x86_64.sh"
class="">https://repo.continuum.io/miniconda/Miniconda3-latest-MacOSX-x86_64.sh</a></font></span></div>
</div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class=""><font class=""
color="#669c35"># Install Miniconda</font></div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class=""><span
style="font-variant-ligatures:
no-common-ligatures;" class="">bash-3.2$ <font
class="" color="#d357fe">bash
Miniconda3-latest-MacOSX-x86_64.sh</font></span></div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class=""><span
style="font-variant-ligatures:
no-common-ligatures;" class="">
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures;" class=""><font class=""
color="#669c35"># Create Python 3.5
Environment</font></span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures;" class="">bash-3.2$ <font
class="" color="#d357fe">conda create -n
python3.4 python=3.4</font></span></div>
<div style="margin: 0px; line-height: normal;"
class=""><font class="" color="#669c35">#
Activate Python 3.5 Environment</font></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures;" class="">bash-3.2$ <font
class="" color="#d357fe">source activate
python3.4</font></span></div>
<div class=""><span style="color: rgb(102, 156,
53);" class=""># Install DAEtools requirements</span></div>
</span></div>
</div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures"
class="">(python3.4) bash-3.2$ <font class=""
color="#d357fe">conda install numpy scipy
matplotlib pyqt lxml pandas h5py xlwt</font></span></div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures"
class="">
<div style="margin: 0px; line-height: normal;"
class=""><span style="color: rgb(102, 156, 53);"
class=""># Download DAEtools</span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures;" class="">
<div style="font-family: Helvetica; font-size:
12px;" class="">
<div style="margin: 0px; font-size: 11px;
line-height: normal; font-family: Menlo;"
class=""><span
style="font-variant-ligatures:
no-common-ligatures;" class="">(python3.4)
bash-3.2$ <font class="" color="#d357fe">curl
-O <a moz-do-not-send="true"
href="https://netcologne.dl.sourceforge.net/project/daetools/1.7.0/daetools-1.7.0-macos-x86_64.tar.gz"
class="">https://netcologne.dl.sourceforge.net/project/daetools/1.7.0/daetools-1.7.0-macos-x86_64.tar.gz</a></font></span></div>
<div style="margin: 0px; font-size: 11px;
line-height: normal; font-family: Menlo;"
class=""><span
style="font-variant-ligatures:
no-common-ligatures;" class=""><font
class="" color="#669c35"># Unpack
DAEtools</font></span></div>
<div style="margin: 0px; font-size: 11px;
line-height: normal; font-family: Menlo;"
class=""><span
style="font-variant-ligatures:
no-common-ligatures;" class="">(python3.4)
bash-3.2$ <font class="" color="#d357fe">tar
xvfz daetools-1.7.0-macos-x86_64.tar.gz</font></span></div>
<div style="margin: 0px; font-size: 11px;
line-height: normal; font-family: Menlo;"
class="">
<div style="margin: 0px; line-height:
normal;" class=""><span
style="font-variant-ligatures:
no-common-ligatures;" class=""><span
style="color: rgb(102, 156, 53);"
class=""># Install DAEtools</span></span></div>
<div style="margin: 0px; line-height:
normal;" class=""><span
style="font-variant-ligatures:
no-common-ligatures;" class=""></span></div>
</div>
<div class=""><span style="font-family: Menlo;
font-size: 11px;" class="">(python3.4)
bash-3.2$ </span><font
style="font-family: Menlo; font-size:
11px;" class="" color="#d357fe">cd
daetools-1.7.0-macos-x86_64-pyqt5/</font></div>
</div>
</span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures;" class="">(python3.4)
bash-3.2$ <font class="" color="#d357fe">sudo
python setup.py install</font></span></div>
</span></div>
<div style="margin: 0px; font-size: 11px; line-height:
normal; font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures"
class="">
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""><span
style="color: rgb(102, 156, 53);" class="">#
Test DAEtools</span></span></div>
<div style="margin: 0px; line-height: normal;"
class="">
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class="">(python3.4)
bash-3.2$ <font class="" color="#d357fe">python</font></span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class="">Python 3.4.5
|Continuum Analytics, Inc.| (default, Jul 2
2016, 17:47:57) </span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class="">[GCC 4.2.1
Compatible Apple LLVM 4.2 (clang-425.0.28)] on
darwin</span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class="">Type "help",
"copyright", "credits" or "license" for more
information.</span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class="">>>> <font
class="" color="#d357fe">import
daetools.pyDAE</font></span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class="">Traceback (most
recent call last):</span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""> File
"<stdin>", line 1, in <module></span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""> File
"/Users/mebner/MPET/daetools-1.7.0-macos-x86_64-pyqt5/daetools/pyDAE/__init__.py",
line 20, in <module></span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""> import
pyCore</span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class="">ImportError:
dlopen(/Users/mebner/MPET/daetools-1.7.0-macos-x86_64-pyqt5/daetools/pyDAE/Darwin_x86_64_py34/pyCore.so,
2): Symbol not found:
__ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev</span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""> Referenced
from:
/Users/mebner/MPET/daetools-1.7.0-macos-x86_64-pyqt5/daetools/pyDAE/Darwin_x86_64_py34/../../solibs/Darwin_x86_64/libboost_system-daetools-py34.dylib</span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""> Expected in:
/usr/lib/libstdc++.6.dylib</span></div>
<div style="margin: 0px; line-height: normal;"
class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""> in
/Users/mebner/MPET/daetools-1.7.0-macos-x86_64-pyqt5/daetools/pyDAE/Darwin_x86_64_py34/../../solibs/Darwin_x86_64/libboost_system-daetools-py34.dylib</span></div>
<div class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""><br class="">
</span></div>
</div>
<div class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""><br class="">
</span></div>
</span></div>
<div class="">
<div style="letter-spacing: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform:
none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<div style="letter-spacing: normal; orphans: auto;
text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; word-wrap:
break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<div style="letter-spacing: normal; orphans: auto;
text-align: start; text-indent: 0px;
text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; word-wrap:
break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<div style="letter-spacing: normal; orphans:
auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; word-wrap:
break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;"
class="">
<div class="">—</div>
<div class="">Dr. Martin Ebner<br class="">
Laboratory for Nanoelectronics<br class="">
Dept. of Electrical Engineering and
Information Technology<br class="">
ETH Zürich<br class="">
<br class="">
address:<br class="">
Gloriastrasse 35, ETZ H65<br class="">
Zürich, 8092 Switzerland<br class="">
<br class="">
email: <a moz-do-not-send="true"
href="mailto:me...@et..." class="">me...@et...</a><br
class="">
phone: +41 (0)44-632-46-03<br class="">
web: <a moz-do-not-send="true"
href="http://lne.ethz.ch/" class="">lne.ethz.ch</a></div>
</div>
</div>
</div>
</div>
</div>
<br class="">
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, <a moz-do-not-send="true" href="http://slashdot.org" class="">Slashdot.org</a>! <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://sdm.link/slashdot">http://sdm.link/slashdot</a></pre>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
daetools-users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:dae...@li...">dae...@li...</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/daetools-users">https://lists.sourceforge.net/lists/listinfo/daetools-users</a>
</pre>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! <a class="moz-txt-link-freetext" href="http://sdm.link/slashdot">http://sdm.link/slashdot</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
daetools-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dae...@li...">dae...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/daetools-users">https://lists.sourceforge.net/lists/listinfo/daetools-users</a>
</pre>
</blockquote>
<br>
</body>
</html>
|
|
From: Ebner M. <me...@et...> - 2017-06-16 22:36:09
|
Dear Dragan, thanks for the tip, that did the trick! # Download HPC-GCC 6.3 bash-3.2$ curl -O https://freefr.dl.sourceforge.net/project/hpc/hpc/gcc/gcc-6.3-bin.tar.gz # Install HPC-GCC 6.3 bash-3.2$ sudo tar -xvf gcc-6.3-bin.tar.gz -C / # … code from below ... # Test DAEtools (python3.4) bash-3.2$ python Python 3.4.5 |Anaconda custom (x86_64)| (default, Jul 2 2016, 17:47:57) [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import daetools.pyDAE >>> # ALL IS FINE! Cheers, Martin! — Dr. Martin Ebner Laboratory for Nanoelectronics Dept. of Electrical Engineering and Information Technology ETH Zürich address: Gloriastrasse 35, ETZ H65 Zürich, 8092 Switzerland email: me...@et... <mailto:me...@et...> phone: +41 (0)44-632-46-03 web: lne.ethz.ch <http://lne.ethz.ch/> > On 17 Jun 2017, at 00:01, Dragan Nikolic <dra...@gm...> wrote: > > Hey Ebner, > > I think it is the std c++ library issue. Good that you use macOS to test it. I compiled the latest release using the g++ compiler that is not from XCode - gcc 6.3 from HPC for Mac website (some libraries won't compile with the clang or gcc from XCode). The most likely the version of std c++ library that comes with mac by default is much older (I think they still use gcc 4.4.2 or something like that) so some symbols are missing. I guess, the quick fix is if you get and install gcc 6.3 from http://hpc.sourceforge.net <http://hpc.sourceforge.net/> it will work. It installs libraries in /usr/local/lib directory I think. Or just copy the libstdc++.6.dylib to /usr/local/lib. I'll try to fix this issue in the meantime (perhaps link statically or provide the std c++ lib with daetools). > > Cheers > Dragan > > On 16/06/17 23:03, Ebner Martin wrote: >> Hi, i’m trying to use daetools-1.7.0 on macOS 10.11.6 with python 3.4 (although i also tried 2.7,3.5,and 3.6). after installing and calling “import daetools.pyDAE”, i get an “Symbol not found” error (see below). I’ve tested the same on a windows machine and there it works fine. am i missing something? >> >> here’s my approach for a clean installation and what happens if i call “import daetools.pyDAE”. >> >> any idea what do do? >> >> thanks, >> Martin >> >> # Download Miniconda >> bash-3.2$ curl -O https://repo.continuum.io/miniconda/Miniconda3-latest-MacOSX-x86_64.sh <https://repo.continuum.io/miniconda/Miniconda3-latest-MacOSX-x86_64.sh> >> # Install Miniconda >> bash-3.2$ bash Miniconda3-latest-MacOSX-x86_64.sh >> # Create Python 3.5 Environment >> bash-3.2$ conda create -n python3.4 python=3.4 >> # Activate Python 3.5 Environment >> bash-3.2$ source activate python3.4 >> # Install DAEtools requirements >> (python3.4) bash-3.2$ conda install numpy scipy matplotlib pyqt lxml pandas h5py xlwt >> # Download DAEtools >> (python3.4) bash-3.2$ curl -O https://netcologne.dl.sourceforge.net/project/daetools/1.7.0/daetools-1.7.0-macos-x86_64.tar.gz <https://netcologne.dl.sourceforge.net/project/daetools/1.7.0/daetools-1.7.0-macos-x86_64.tar.gz> >> # Unpack DAEtools >> (python3.4) bash-3.2$ tar xvfz daetools-1.7.0-macos-x86_64.tar.gz >> # Install DAEtools >> (python3.4) bash-3.2$ cd daetools-1.7.0-macos-x86_64-pyqt5/ >> (python3.4) bash-3.2$ sudo python setup.py install >> # Test DAEtools >> (python3.4) bash-3.2$ python >> Python 3.4.5 |Continuum Analytics, Inc.| (default, Jul 2 2016, 17:47:57) >> [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import daetools.pyDAE >> Traceback (most recent call last): >> File "<stdin>", line 1, in <module> >> File "/Users/mebner/MPET/daetools-1.7.0-macos-x86_64-pyqt5/daetools/pyDAE/__init__.py", line 20, in <module> >> import pyCore >> ImportError: dlopen(/Users/mebner/MPET/daetools-1.7.0-macos-x86_64-pyqt5/daetools/pyDAE/Darwin_x86_64_py34/pyCore.so, 2): Symbol not found: __ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev >> Referenced from: /Users/mebner/MPET/daetools-1.7.0-macos-x86_64-pyqt5/daetools/pyDAE/Darwin_x86_64_py34/../../solibs/Darwin_x86_64/libboost_system-daetools-py34.dylib >> Expected in: /usr/lib/libstdc++.6.dylib >> in /Users/mebner/MPET/daetools-1.7.0-macos-x86_64-pyqt5/daetools/pyDAE/Darwin_x86_64_py34/../../solibs/Darwin_x86_64/libboost_system-daetools-py34.dylib >> >> >> — >> Dr. Martin Ebner >> Laboratory for Nanoelectronics >> Dept. of Electrical Engineering and Information Technology >> ETH Zürich >> >> address: >> Gloriastrasse 35, ETZ H65 >> Zürich, 8092 Switzerland >> >> email: me...@et... <mailto:me...@et...> >> phone: +41 (0)44-632-46-03 >> web: lne.ethz.ch <http://lne.ethz.ch/> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot> >> >> _______________________________________________ >> daetools-users mailing list >> dae...@li... <mailto:dae...@li...> >> https://lists.sourceforge.net/lists/listinfo/daetools-users <https://lists.sourceforge.net/lists/listinfo/daetools-users> > |
|
From: Ebner M. <me...@et...> - 2017-06-16 21:16:11
|
Hi, i’m trying to use daetools-1.7.0 on macOS 10.11.6 with python 3.4 (although i also tried 2.7,3.5,and 3.6). after installing and calling “import daetools.pyDAE”, i get an “Symbol not found” error (see below). I’ve tested the same on a windows machine and there it works fine. am i missing something? here’s my approach for a clean installation and what happens if i call “import daetools.pyDAE”. any idea what do do? thanks, Martin # Download Miniconda bash-3.2$ curl -O https://repo.continuum.io/miniconda/Miniconda3-latest-MacOSX-x86_64.sh # Install Miniconda bash-3.2$ bash Miniconda3-latest-MacOSX-x86_64.sh # Create Python 3.5 Environment bash-3.2$ conda create -n python3.4 python=3.4 # Activate Python 3.5 Environment bash-3.2$ source activate python3.4 # Install DAEtools requirements (python3.4) bash-3.2$ conda install numpy scipy matplotlib pyqt lxml pandas h5py xlwt # Download DAEtools (python3.4) bash-3.2$ curl -O https://netcologne.dl.sourceforge.net/project/daetools/1.7.0/daetools-1.7.0-macos-x86_64.tar.gz # Unpack DAEtools (python3.4) bash-3.2$ tar xvfz daetools-1.7.0-macos-x86_64.tar.gz # Install DAEtools (python3.4) bash-3.2$ cd daetools-1.7.0-macos-x86_64-pyqt5/ (python3.4) bash-3.2$ sudo python setup.py install # Test DAEtools (python3.4) bash-3.2$ python Python 3.4.5 |Continuum Analytics, Inc.| (default, Jul 2 2016, 17:47:57) [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import daetools.pyDAE Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Users/mebner/MPET/daetools-1.7.0-macos-x86_64-pyqt5/daetools/pyDAE/__init__.py", line 20, in <module> import pyCore ImportError: dlopen(/Users/mebner/MPET/daetools-1.7.0-macos-x86_64-pyqt5/daetools/pyDAE/Darwin_x86_64_py34/pyCore.so, 2): Symbol not found: __ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev Referenced from: /Users/mebner/MPET/daetools-1.7.0-macos-x86_64-pyqt5/daetools/pyDAE/Darwin_x86_64_py34/../../solibs/Darwin_x86_64/libboost_system-daetools-py34.dylib Expected in: /usr/lib/libstdc++.6.dylib in /Users/mebner/MPET/daetools-1.7.0-macos-x86_64-pyqt5/daetools/pyDAE/Darwin_x86_64_py34/../../solibs/Darwin_x86_64/libboost_system-daetools-py34.dylib — Dr. Martin Ebner Laboratory for Nanoelectronics Dept. of Electrical Engineering and Information Technology ETH Zürich address: Gloriastrasse 35, ETZ H65 Zürich, 8092 Switzerland email: me...@et... <mailto:me...@et...> phone: +41 (0)44-632-46-03 web: lne.ethz.ch <http://lne.ethz.ch/> |
|
From: Dragan N. <dra...@gm...> - 2017-01-17 17:58:51
|
No problem. Yes, it should fix them both, it's the same bug. And yes, I remembered that inconsistency you mentioned once. Dimensionless numbers do not fit well with everything else with units. I found some others, not related to you at the moment. 1.6.0 will be soon out. Dragan On 17/01/17 18:47, Raymond Smith wrote: > Wonderful, thanks! It does fix the simple case as you could test, and > it also fixes the more complete case, which is not surprising, but > very nice. > > I also see that the structured grid can accept Quantity objects now. > If I remember, I'll update the battery simulation example once 1.6.0 > comes out or you release a new beta. > > Ray > > On Tue, Jan 17, 2017 at 4:39 AM, Dragan Nikolic <dra...@gm... > <mailto:dra...@gm...>> wrote: > > I committed a new revision with the fix for the issue you > discovered. I tried and it should work well now. > > Dragan > > > On 15/01/17 22:29, Raymond Smith wrote: > > Cool, thanks for the update. That strikes me as a curious > choice for the default, but I'm guessing the SUNDIALS > developers have their reasons. > > Tangentially, daetools builds and runs fine with with py36 (as > well as py35), which I learned when Arch Linux updated to > py36. I'm happy to build and share the binaries with you if > you want to host them. Up to you. > > Ray > > On Sun, Jan 15, 2017 at 1:15 PM, Dragan Nikolic > <dra...@gm... <mailto:dra...@gm...> > <mailto:dra...@gm... <mailto:dra...@gm...>>> > wrote: > > Yes, the stop time should be specified in IDA solver (with > IDASetStopTime) to prevent these kind of situations where the > solver takes long time steps, past the time horizon set in the > simulation. The default stop time is infinity and that's > why your > situation happens. I had that before but for some reasons I > removed it at some point. I'll check why. I'll update the > source > at some point soon. > > Dragan > > > On 15/01/17 00:26, Raymond Smith wrote: > > Thanks, and you too! > > I was suspicious it was a result of a overly > aggressive time > stepping, as that was the only way this system should > get into > negative log regimes, but I hadn't made it print things to > actually narrow it down. In the meantime, I have a > similar-looking function which behaves a bit better, > so I can > use that for now, but I'll also be curious to hear > what you find. > > On Sat, Jan 14, 2017 at 12:44 PM, Dragan Nikolic > <dra...@gm... <mailto:dra...@gm...> > <mailto:dra...@gm... <mailto:dra...@gm...>> > <mailto:dra...@gm... > <mailto:dra...@gm...> <mailto:dra...@gm... > <mailto:dra...@gm...>>>> > > wrote: > > Hello Ray, > > Greetings to you and happy and prosperous New Year. > > It is strange and it is not :-) Advanced solvers > try to > take as long > steps as possible. If you switch on > daetools.core.printInfo in > daetools.cfg and re-run simulation you can see > that IDAS > solver take > long steps internally but when the results for > intermediate time > points > are requested does some kind of interpolation > using the > BDF data it > keeps. If the system is not stiff the time steps > can be > very long. In > your case I get this: > > Calculate residuals at time 126.410696314185998... > > At that time y is probably greater than 1.0 and > you get > log of a > negative value exception in reg_sln function. > > Honestly, I thought I fixed this long time ago > (meaning > that DAE > solver > shouldn't take larger steps than TimeHorizon) but > I will > check what is > going on and appearing again. > > Dragan > > > On 14/01/17 20:24, Raymond Smith wrote: > > Greetings. > > > > I've got a behavior I can't explain in one of my > simulations, so I > > tried to come up with a simplified example to > demonstrate it. The > > behavior in the simplified version isn't quite > the same > as the > > behavior in the full version, but it seems like > it might > be related. > > And in any case, I can't explain the behavior of the > simplified > > version either, so it's still curious. > > > > I've attached a simple example of 3 coupled DAE's > (inspired by a > > battery model, much like that on the daetools > website). > When I > use one > > function for the equilibrium potential of the > electrode > material, it > > behaves nicely. However, when I use a similar > function, the > simulation > > crashes with negative log errors which shouldn't be > occurring I > > believe. To run the crashing version, start > daeplotter, then > > > > $ python battery_simple.py [console] > > > > I get it crashing at ~75.5 time units. This > seems wrong > to me > because > > when I use a different but similar function for the > equilibrium > > potential it works fine. To do this, toggle the > comment > status of > > lines 44 & 45, then it should run fine. > > > > To demonstrate that the functions are similar, > you can run > > > > $ python battery_simple.py plot > > > > and it will compare the two functions we're > using for the > equilibrium > > potential. Any ideas why the desired one leads to > crashes (and > perhaps > > how to avoid them)? > > > > Thanks, > > Ray > > > > > > > > ------------------------------------------------------------------------------ > > Developer Access Program for Intel Xeon Phi > Processors > > Access to Intel Xeon Phi processor-based developer > platforms. > > With one year of Intel Parallel Studio XE. > > Training and support from Colfax. > > Order your platform today. http://sdm.link/xeonphi > > > > > > _______________________________________________ > > daetools-users mailing list > > dae...@li... > <mailto:dae...@li...> > <mailto:dae...@li... > <mailto:dae...@li...>> > <mailto:dae...@li... > <mailto:dae...@li...> > <mailto:dae...@li... > <mailto:dae...@li...>>> > > > https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users> > > <https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users>> > > <https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users> > > <https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users>>> > > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer > platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > daetools-users mailing list > dae...@li... > <mailto:dae...@li...> > <mailto:dae...@li... > <mailto:dae...@li...>> > <mailto:dae...@li... > <mailto:dae...@li...> > <mailto:dae...@li... > <mailto:dae...@li...>>> > https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users> > > <https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users>> > > <https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users> > > <https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users>>> > > > > > > |
|
From: Raymond S. <sm...@mi...> - 2017-01-17 17:47:51
|
Wonderful, thanks! It does fix the simple case as you could test, and it also fixes the more complete case, which is not surprising, but very nice. I also see that the structured grid can accept Quantity objects now. If I remember, I'll update the battery simulation example once 1.6.0 comes out or you release a new beta. Ray On Tue, Jan 17, 2017 at 4:39 AM, Dragan Nikolic <dra...@gm...> wrote: > I committed a new revision with the fix for the issue you discovered. I > tried and it should work well now. > > Dragan > > > On 15/01/17 22:29, Raymond Smith wrote: > >> Cool, thanks for the update. That strikes me as a curious choice for the >> default, but I'm guessing the SUNDIALS developers have their reasons. >> >> Tangentially, daetools builds and runs fine with with py36 (as well as >> py35), which I learned when Arch Linux updated to py36. I'm happy to build >> and share the binaries with you if you want to host them. Up to you. >> >> Ray >> >> On Sun, Jan 15, 2017 at 1:15 PM, Dragan Nikolic <dra...@gm... >> <mailto:dra...@gm...>> wrote: >> >> Yes, the stop time should be specified in IDA solver (with >> IDASetStopTime) to prevent these kind of situations where the >> solver takes long time steps, past the time horizon set in the >> simulation. The default stop time is infinity and that's why your >> situation happens. I had that before but for some reasons I >> removed it at some point. I'll check why. I'll update the source >> at some point soon. >> >> Dragan >> >> >> On 15/01/17 00:26, Raymond Smith wrote: >> >> Thanks, and you too! >> >> I was suspicious it was a result of a overly aggressive time >> stepping, as that was the only way this system should get into >> negative log regimes, but I hadn't made it print things to >> actually narrow it down. In the meantime, I have a >> similar-looking function which behaves a bit better, so I can >> use that for now, but I'll also be curious to hear what you find. >> >> On Sat, Jan 14, 2017 at 12:44 PM, Dragan Nikolic >> <dra...@gm... <mailto:dra...@gm...> >> <mailto:dra...@gm... <mailto:dra...@gm...>>> >> >> wrote: >> >> Hello Ray, >> >> Greetings to you and happy and prosperous New Year. >> >> It is strange and it is not :-) Advanced solvers try to >> take as long >> steps as possible. If you switch on daetools.core.printInfo in >> daetools.cfg and re-run simulation you can see that IDAS >> solver take >> long steps internally but when the results for >> intermediate time >> points >> are requested does some kind of interpolation using the >> BDF data it >> keeps. If the system is not stiff the time steps can be >> very long. In >> your case I get this: >> >> Calculate residuals at time 126.410696314185998... >> >> At that time y is probably greater than 1.0 and you get >> log of a >> negative value exception in reg_sln function. >> >> Honestly, I thought I fixed this long time ago (meaning >> that DAE >> solver >> shouldn't take larger steps than TimeHorizon) but I will >> check what is >> going on and appearing again. >> >> Dragan >> >> >> On 14/01/17 20:24, Raymond Smith wrote: >> > Greetings. >> > >> > I've got a behavior I can't explain in one of my >> simulations, so I >> > tried to come up with a simplified example to >> demonstrate it. The >> > behavior in the simplified version isn't quite the same >> as the >> > behavior in the full version, but it seems like it might >> be related. >> > And in any case, I can't explain the behavior of the >> simplified >> > version either, so it's still curious. >> > >> > I've attached a simple example of 3 coupled DAE's >> (inspired by a >> > battery model, much like that on the daetools website). >> When I >> use one >> > function for the equilibrium potential of the electrode >> material, it >> > behaves nicely. However, when I use a similar function, the >> simulation >> > crashes with negative log errors which shouldn't be >> occurring I >> > believe. To run the crashing version, start daeplotter, then >> > >> > $ python battery_simple.py [console] >> > >> > I get it crashing at ~75.5 time units. This seems wrong >> to me >> because >> > when I use a different but similar function for the >> equilibrium >> > potential it works fine. To do this, toggle the comment >> status of >> > lines 44 & 45, then it should run fine. >> > >> > To demonstrate that the functions are similar, you can run >> > >> > $ python battery_simple.py plot >> > >> > and it will compare the two functions we're using for the >> equilibrium >> > potential. Any ideas why the desired one leads to >> crashes (and >> perhaps >> > how to avoid them)? >> > >> > Thanks, >> > Ray >> > >> > >> > >> ----------------------------- >> ------------------------------------------------- >> > Developer Access Program for Intel Xeon Phi Processors >> > Access to Intel Xeon Phi processor-based developer >> platforms. >> > With one year of Intel Parallel Studio XE. >> > Training and support from Colfax. >> > Order your platform today. http://sdm.link/xeonphi >> > >> > >> > _______________________________________________ >> > daetools-users mailing list >> > dae...@li... >> <mailto:dae...@li...> >> <mailto:dae...@li... >> <mailto:dae...@li...>> >> > >> https://lists.sourceforge.net/lists/listinfo/daetools-users >> <https://lists.sourceforge.net/lists/listinfo/daetools-users> >> <https://lists.sourceforge.ne >> t/lists/listinfo/daetools-users >> <https://lists.sourceforge.net/lists/listinfo/daetools-users>> >> >> >> ----------------------------- >> ------------------------------------------------- >> Developer Access Program for Intel Xeon Phi Processors >> Access to Intel Xeon Phi processor-based developer platforms. >> With one year of Intel Parallel Studio XE. >> Training and support from Colfax. >> Order your platform today. http://sdm.link/xeonphi >> _______________________________________________ >> daetools-users mailing list >> dae...@li... >> <mailto:dae...@li...> >> <mailto:dae...@li... >> <mailto:dae...@li...>> >> https://lists.sourceforge.net/lists/listinfo/daetools-users >> <https://lists.sourceforge.net/lists/listinfo/daetools-users> >> <https://lists.sourceforge.ne >> t/lists/listinfo/daetools-users >> <https://lists.sourceforge.net/lists/listinfo/daetools-users>> >> >> >> >> >> > |
|
From: Dragan N. <dra...@gm...> - 2017-01-17 12:39:41
|
I committed a new revision with the fix for the issue you discovered. I tried and it should work well now. Dragan On 15/01/17 22:29, Raymond Smith wrote: > Cool, thanks for the update. That strikes me as a curious choice for > the default, but I'm guessing the SUNDIALS developers have their reasons. > > Tangentially, daetools builds and runs fine with with py36 (as well as > py35), which I learned when Arch Linux updated to py36. I'm happy to > build and share the binaries with you if you want to host them. Up to you. > > Ray > > On Sun, Jan 15, 2017 at 1:15 PM, Dragan Nikolic <dra...@gm... > <mailto:dra...@gm...>> wrote: > > Yes, the stop time should be specified in IDA solver (with > IDASetStopTime) to prevent these kind of situations where the > solver takes long time steps, past the time horizon set in the > simulation. The default stop time is infinity and that's why your > situation happens. I had that before but for some reasons I > removed it at some point. I'll check why. I'll update the source > at some point soon. > > Dragan > > > On 15/01/17 00:26, Raymond Smith wrote: > > Thanks, and you too! > > I was suspicious it was a result of a overly aggressive time > stepping, as that was the only way this system should get into > negative log regimes, but I hadn't made it print things to > actually narrow it down. In the meantime, I have a > similar-looking function which behaves a bit better, so I can > use that for now, but I'll also be curious to hear what you find. > > On Sat, Jan 14, 2017 at 12:44 PM, Dragan Nikolic > <dra...@gm... <mailto:dra...@gm...> > <mailto:dra...@gm... <mailto:dra...@gm...>>> > wrote: > > Hello Ray, > > Greetings to you and happy and prosperous New Year. > > It is strange and it is not :-) Advanced solvers try to > take as long > steps as possible. If you switch on daetools.core.printInfo in > daetools.cfg and re-run simulation you can see that IDAS > solver take > long steps internally but when the results for > intermediate time > points > are requested does some kind of interpolation using the > BDF data it > keeps. If the system is not stiff the time steps can be > very long. In > your case I get this: > > Calculate residuals at time 126.410696314185998... > > At that time y is probably greater than 1.0 and you get > log of a > negative value exception in reg_sln function. > > Honestly, I thought I fixed this long time ago (meaning > that DAE > solver > shouldn't take larger steps than TimeHorizon) but I will > check what is > going on and appearing again. > > Dragan > > > On 14/01/17 20:24, Raymond Smith wrote: > > Greetings. > > > > I've got a behavior I can't explain in one of my > simulations, so I > > tried to come up with a simplified example to > demonstrate it. The > > behavior in the simplified version isn't quite the same > as the > > behavior in the full version, but it seems like it might > be related. > > And in any case, I can't explain the behavior of the > simplified > > version either, so it's still curious. > > > > I've attached a simple example of 3 coupled DAE's > (inspired by a > > battery model, much like that on the daetools website). > When I > use one > > function for the equilibrium potential of the electrode > material, it > > behaves nicely. However, when I use a similar function, the > simulation > > crashes with negative log errors which shouldn't be > occurring I > > believe. To run the crashing version, start daeplotter, then > > > > $ python battery_simple.py [console] > > > > I get it crashing at ~75.5 time units. This seems wrong > to me > because > > when I use a different but similar function for the > equilibrium > > potential it works fine. To do this, toggle the comment > status of > > lines 44 & 45, then it should run fine. > > > > To demonstrate that the functions are similar, you can run > > > > $ python battery_simple.py plot > > > > and it will compare the two functions we're using for the > equilibrium > > potential. Any ideas why the desired one leads to > crashes (and > perhaps > > how to avoid them)? > > > > Thanks, > > Ray > > > > > > > > ------------------------------------------------------------------------------ > > Developer Access Program for Intel Xeon Phi Processors > > Access to Intel Xeon Phi processor-based developer > platforms. > > With one year of Intel Parallel Studio XE. > > Training and support from Colfax. > > Order your platform today. http://sdm.link/xeonphi > > > > > > _______________________________________________ > > daetools-users mailing list > > dae...@li... > <mailto:dae...@li...> > <mailto:dae...@li... > <mailto:dae...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users> > > <https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users>> > > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > daetools-users mailing list > dae...@li... > <mailto:dae...@li...> > <mailto:dae...@li... > <mailto:dae...@li...>> > https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users> > > <https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users>> > > > > |
|
From: Dragan N. <dra...@gm...> - 2017-01-15 21:49:31
|
Well, in a general case that's probably the best (+infinity). I think I did try compile for py3.6 myself and it worked (for GNU/Linux only), anyway it will be in the next release. For windows the last python supported by mingw cross-compiler is 3.4 and until they find a way to support new universal stdlibs it will stay there. On 15/01/17 22:29, Raymond Smith wrote: > Cool, thanks for the update. That strikes me as a curious choice for > the default, but I'm guessing the SUNDIALS developers have their reasons. > > Tangentially, daetools builds and runs fine with with py36 (as well as > py35), which I learned when Arch Linux updated to py36. I'm happy to > build and share the binaries with you if you want to host them. Up to you. > > Ray > > On Sun, Jan 15, 2017 at 1:15 PM, Dragan Nikolic <dra...@gm... > <mailto:dra...@gm...>> wrote: > > Yes, the stop time should be specified in IDA solver (with > IDASetStopTime) to prevent these kind of situations where the > solver takes long time steps, past the time horizon set in the > simulation. The default stop time is infinity and that's why your > situation happens. I had that before but for some reasons I > removed it at some point. I'll check why. I'll update the source > at some point soon. > > Dragan > > > On 15/01/17 00:26, Raymond Smith wrote: > > Thanks, and you too! > > I was suspicious it was a result of a overly aggressive time > stepping, as that was the only way this system should get into > negative log regimes, but I hadn't made it print things to > actually narrow it down. In the meantime, I have a > similar-looking function which behaves a bit better, so I can > use that for now, but I'll also be curious to hear what you find. > > On Sat, Jan 14, 2017 at 12:44 PM, Dragan Nikolic > <dra...@gm... <mailto:dra...@gm...> > <mailto:dra...@gm... <mailto:dra...@gm...>>> > wrote: > > Hello Ray, > > Greetings to you and happy and prosperous New Year. > > It is strange and it is not :-) Advanced solvers try to > take as long > steps as possible. If you switch on daetools.core.printInfo in > daetools.cfg and re-run simulation you can see that IDAS > solver take > long steps internally but when the results for > intermediate time > points > are requested does some kind of interpolation using the > BDF data it > keeps. If the system is not stiff the time steps can be > very long. In > your case I get this: > > Calculate residuals at time 126.410696314185998... > > At that time y is probably greater than 1.0 and you get > log of a > negative value exception in reg_sln function. > > Honestly, I thought I fixed this long time ago (meaning > that DAE > solver > shouldn't take larger steps than TimeHorizon) but I will > check what is > going on and appearing again. > > Dragan > > > On 14/01/17 20:24, Raymond Smith wrote: > > Greetings. > > > > I've got a behavior I can't explain in one of my > simulations, so I > > tried to come up with a simplified example to > demonstrate it. The > > behavior in the simplified version isn't quite the same > as the > > behavior in the full version, but it seems like it might > be related. > > And in any case, I can't explain the behavior of the > simplified > > version either, so it's still curious. > > > > I've attached a simple example of 3 coupled DAE's > (inspired by a > > battery model, much like that on the daetools website). > When I > use one > > function for the equilibrium potential of the electrode > material, it > > behaves nicely. However, when I use a similar function, the > simulation > > crashes with negative log errors which shouldn't be > occurring I > > believe. To run the crashing version, start daeplotter, then > > > > $ python battery_simple.py [console] > > > > I get it crashing at ~75.5 time units. This seems wrong > to me > because > > when I use a different but similar function for the > equilibrium > > potential it works fine. To do this, toggle the comment > status of > > lines 44 & 45, then it should run fine. > > > > To demonstrate that the functions are similar, you can run > > > > $ python battery_simple.py plot > > > > and it will compare the two functions we're using for the > equilibrium > > potential. Any ideas why the desired one leads to > crashes (and > perhaps > > how to avoid them)? > > > > Thanks, > > Ray > > > > > > > > ------------------------------------------------------------------------------ > > Developer Access Program for Intel Xeon Phi Processors > > Access to Intel Xeon Phi processor-based developer > platforms. > > With one year of Intel Parallel Studio XE. > > Training and support from Colfax. > > Order your platform today. http://sdm.link/xeonphi > > > > > > _______________________________________________ > > daetools-users mailing list > > dae...@li... > <mailto:dae...@li...> > <mailto:dae...@li... > <mailto:dae...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users> > > <https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users>> > > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > daetools-users mailing list > dae...@li... > <mailto:dae...@li...> > <mailto:dae...@li... > <mailto:dae...@li...>> > https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users> > > <https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users>> > > > > |
|
From: Raymond S. <sm...@mi...> - 2017-01-15 21:30:23
|
Cool, thanks for the update. That strikes me as a curious choice for the default, but I'm guessing the SUNDIALS developers have their reasons. Tangentially, daetools builds and runs fine with with py36 (as well as py35), which I learned when Arch Linux updated to py36. I'm happy to build and share the binaries with you if you want to host them. Up to you. Ray On Sun, Jan 15, 2017 at 1:15 PM, Dragan Nikolic <dra...@gm...> wrote: > Yes, the stop time should be specified in IDA solver (with IDASetStopTime) > to prevent these kind of situations where the solver takes long time steps, > past the time horizon set in the simulation. The default stop time is > infinity and that's why your situation happens. I had that before but for > some reasons I removed it at some point. I'll check why. I'll update the > source at some point soon. > > Dragan > > > On 15/01/17 00:26, Raymond Smith wrote: > >> Thanks, and you too! >> >> I was suspicious it was a result of a overly aggressive time stepping, as >> that was the only way this system should get into negative log regimes, but >> I hadn't made it print things to actually narrow it down. In the meantime, >> I have a similar-looking function which behaves a bit better, so I can use >> that for now, but I'll also be curious to hear what you find. >> >> On Sat, Jan 14, 2017 at 12:44 PM, Dragan Nikolic <dra...@gm... >> <mailto:dra...@gm...>> wrote: >> >> Hello Ray, >> >> Greetings to you and happy and prosperous New Year. >> >> It is strange and it is not :-) Advanced solvers try to take as long >> steps as possible. If you switch on daetools.core.printInfo in >> daetools.cfg and re-run simulation you can see that IDAS solver take >> long steps internally but when the results for intermediate time >> points >> are requested does some kind of interpolation using the BDF data it >> keeps. If the system is not stiff the time steps can be very long. In >> your case I get this: >> >> Calculate residuals at time 126.410696314185998... >> >> At that time y is probably greater than 1.0 and you get log of a >> negative value exception in reg_sln function. >> >> Honestly, I thought I fixed this long time ago (meaning that DAE >> solver >> shouldn't take larger steps than TimeHorizon) but I will check what is >> going on and appearing again. >> >> Dragan >> >> >> On 14/01/17 20:24, Raymond Smith wrote: >> > Greetings. >> > >> > I've got a behavior I can't explain in one of my simulations, so I >> > tried to come up with a simplified example to demonstrate it. The >> > behavior in the simplified version isn't quite the same as the >> > behavior in the full version, but it seems like it might be related. >> > And in any case, I can't explain the behavior of the simplified >> > version either, so it's still curious. >> > >> > I've attached a simple example of 3 coupled DAE's (inspired by a >> > battery model, much like that on the daetools website). When I >> use one >> > function for the equilibrium potential of the electrode material, it >> > behaves nicely. However, when I use a similar function, the >> simulation >> > crashes with negative log errors which shouldn't be occurring I >> > believe. To run the crashing version, start daeplotter, then >> > >> > $ python battery_simple.py [console] >> > >> > I get it crashing at ~75.5 time units. This seems wrong to me >> because >> > when I use a different but similar function for the equilibrium >> > potential it works fine. To do this, toggle the comment status of >> > lines 44 & 45, then it should run fine. >> > >> > To demonstrate that the functions are similar, you can run >> > >> > $ python battery_simple.py plot >> > >> > and it will compare the two functions we're using for the >> equilibrium >> > potential. Any ideas why the desired one leads to crashes (and >> perhaps >> > how to avoid them)? >> > >> > Thanks, >> > Ray >> > >> > >> > >> ------------------------------------------------------------ >> ------------------ >> > Developer Access Program for Intel Xeon Phi Processors >> > Access to Intel Xeon Phi processor-based developer platforms. >> > With one year of Intel Parallel Studio XE. >> > Training and support from Colfax. >> > Order your platform today. http://sdm.link/xeonphi >> > >> > >> > _______________________________________________ >> > daetools-users mailing list >> > dae...@li... >> <mailto:dae...@li...> >> > https://lists.sourceforge.net/lists/listinfo/daetools-users >> <https://lists.sourceforge.net/lists/listinfo/daetools-users> >> >> >> ------------------------------------------------------------ >> ------------------ >> Developer Access Program for Intel Xeon Phi Processors >> Access to Intel Xeon Phi processor-based developer platforms. >> With one year of Intel Parallel Studio XE. >> Training and support from Colfax. >> Order your platform today. http://sdm.link/xeonphi >> _______________________________________________ >> daetools-users mailing list >> dae...@li... >> <mailto:dae...@li...> >> https://lists.sourceforge.net/lists/listinfo/daetools-users >> <https://lists.sourceforge.net/lists/listinfo/daetools-users> >> >> >> > |
|
From: Dragan N. <dra...@gm...> - 2017-01-15 21:15:53
|
Yes, the stop time should be specified in IDA solver (with IDASetStopTime) to prevent these kind of situations where the solver takes long time steps, past the time horizon set in the simulation. The default stop time is infinity and that's why your situation happens. I had that before but for some reasons I removed it at some point. I'll check why. I'll update the source at some point soon. Dragan On 15/01/17 00:26, Raymond Smith wrote: > Thanks, and you too! > > I was suspicious it was a result of a overly aggressive time stepping, > as that was the only way this system should get into negative log > regimes, but I hadn't made it print things to actually narrow it down. > In the meantime, I have a similar-looking function which behaves a bit > better, so I can use that for now, but I'll also be curious to hear > what you find. > > On Sat, Jan 14, 2017 at 12:44 PM, Dragan Nikolic > <dra...@gm... <mailto:dra...@gm...>> wrote: > > Hello Ray, > > Greetings to you and happy and prosperous New Year. > > It is strange and it is not :-) Advanced solvers try to take as long > steps as possible. If you switch on daetools.core.printInfo in > daetools.cfg and re-run simulation you can see that IDAS solver take > long steps internally but when the results for intermediate time > points > are requested does some kind of interpolation using the BDF data it > keeps. If the system is not stiff the time steps can be very long. In > your case I get this: > > Calculate residuals at time 126.410696314185998... > > At that time y is probably greater than 1.0 and you get log of a > negative value exception in reg_sln function. > > Honestly, I thought I fixed this long time ago (meaning that DAE > solver > shouldn't take larger steps than TimeHorizon) but I will check what is > going on and appearing again. > > Dragan > > > On 14/01/17 20:24, Raymond Smith wrote: > > Greetings. > > > > I've got a behavior I can't explain in one of my simulations, so I > > tried to come up with a simplified example to demonstrate it. The > > behavior in the simplified version isn't quite the same as the > > behavior in the full version, but it seems like it might be related. > > And in any case, I can't explain the behavior of the simplified > > version either, so it's still curious. > > > > I've attached a simple example of 3 coupled DAE's (inspired by a > > battery model, much like that on the daetools website). When I > use one > > function for the equilibrium potential of the electrode material, it > > behaves nicely. However, when I use a similar function, the > simulation > > crashes with negative log errors which shouldn't be occurring I > > believe. To run the crashing version, start daeplotter, then > > > > $ python battery_simple.py [console] > > > > I get it crashing at ~75.5 time units. This seems wrong to me > because > > when I use a different but similar function for the equilibrium > > potential it works fine. To do this, toggle the comment status of > > lines 44 & 45, then it should run fine. > > > > To demonstrate that the functions are similar, you can run > > > > $ python battery_simple.py plot > > > > and it will compare the two functions we're using for the > equilibrium > > potential. Any ideas why the desired one leads to crashes (and > perhaps > > how to avoid them)? > > > > Thanks, > > Ray > > > > > > > ------------------------------------------------------------------------------ > > Developer Access Program for Intel Xeon Phi Processors > > Access to Intel Xeon Phi processor-based developer platforms. > > With one year of Intel Parallel Studio XE. > > Training and support from Colfax. > > Order your platform today. http://sdm.link/xeonphi > > > > > > _______________________________________________ > > daetools-users mailing list > > dae...@li... > <mailto:dae...@li...> > > https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users> > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > daetools-users mailing list > dae...@li... > <mailto:dae...@li...> > https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users> > > |
|
From: Dragan N. <dra...@gm...> - 2017-01-15 11:51:03
|
Thank you. I will check what is going on. As I said, I thought I fixed it. Usually the exception does not appear for the time steps taken are smaller and there are no log terms or the arguments are positive. Good that you found it out. The fix should be simple, I think. Cheers, Dragan On 15/01/17 00:26, Raymond Smith wrote: > Thanks, and you too! > > I was suspicious it was a result of a overly aggressive time stepping, > as that was the only way this system should get into negative log > regimes, but I hadn't made it print things to actually narrow it down. > In the meantime, I have a similar-looking function which behaves a bit > better, so I can use that for now, but I'll also be curious to hear > what you find. > > On Sat, Jan 14, 2017 at 12:44 PM, Dragan Nikolic > <dra...@gm... <mailto:dra...@gm...>> wrote: > > Hello Ray, > > Greetings to you and happy and prosperous New Year. > > It is strange and it is not :-) Advanced solvers try to take as long > steps as possible. If you switch on daetools.core.printInfo in > daetools.cfg and re-run simulation you can see that IDAS solver take > long steps internally but when the results for intermediate time > points > are requested does some kind of interpolation using the BDF data it > keeps. If the system is not stiff the time steps can be very long. In > your case I get this: > > Calculate residuals at time 126.410696314185998... > > At that time y is probably greater than 1.0 and you get log of a > negative value exception in reg_sln function. > > Honestly, I thought I fixed this long time ago (meaning that DAE > solver > shouldn't take larger steps than TimeHorizon) but I will check what is > going on and appearing again. > > Dragan > > > On 14/01/17 20:24, Raymond Smith wrote: > > Greetings. > > > > I've got a behavior I can't explain in one of my simulations, so I > > tried to come up with a simplified example to demonstrate it. The > > behavior in the simplified version isn't quite the same as the > > behavior in the full version, but it seems like it might be related. > > And in any case, I can't explain the behavior of the simplified > > version either, so it's still curious. > > > > I've attached a simple example of 3 coupled DAE's (inspired by a > > battery model, much like that on the daetools website). When I > use one > > function for the equilibrium potential of the electrode material, it > > behaves nicely. However, when I use a similar function, the > simulation > > crashes with negative log errors which shouldn't be occurring I > > believe. To run the crashing version, start daeplotter, then > > > > $ python battery_simple.py [console] > > > > I get it crashing at ~75.5 time units. This seems wrong to me > because > > when I use a different but similar function for the equilibrium > > potential it works fine. To do this, toggle the comment status of > > lines 44 & 45, then it should run fine. > > > > To demonstrate that the functions are similar, you can run > > > > $ python battery_simple.py plot > > > > and it will compare the two functions we're using for the > equilibrium > > potential. Any ideas why the desired one leads to crashes (and > perhaps > > how to avoid them)? > > > > Thanks, > > Ray > > > > > > > ------------------------------------------------------------------------------ > > Developer Access Program for Intel Xeon Phi Processors > > Access to Intel Xeon Phi processor-based developer platforms. > > With one year of Intel Parallel Studio XE. > > Training and support from Colfax. > > Order your platform today. http://sdm.link/xeonphi > > > > > > _______________________________________________ > > daetools-users mailing list > > dae...@li... > <mailto:dae...@li...> > > https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users> > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > daetools-users mailing list > dae...@li... > <mailto:dae...@li...> > https://lists.sourceforge.net/lists/listinfo/daetools-users > <https://lists.sourceforge.net/lists/listinfo/daetools-users> > > |
21 messages has been excluded from this view by a project administrator.
