ecell-devel Mailing List for E-Cell System

hi,


Another thing that needs to be decided is how different types of 
Steppers and Processes are related.

Stepper has two types: discrete and continuous.   Continuous Steppers
requires their Processes to manipulate Variables with
velocity  (via Process::setFlux() or Variable::addVelocity()).   
On the other hand, discrete Steppers 
generally require their Processes to use direct methods such as
Process::addValue or Variable::setValue().

Discrete steppers inherits from either DiscreteTimeStepper or
DiscreteEventStepper. Currently all continuous Steppers are subclasses
of DifferentialStepper.


One thing decided so far is Processes used by DiscreteEventStepper
are subclasses of DiscreteEventProcess.   This is because the
DiscreteEventSteppers require their Processes to have some special
methods such as getStepInterval().
So DiscreteEventStepper/DiscreteEventProcess pair is ok.   They can 
always check that they are connected with correct partners.


But a problem is how to distinguish continuous and discrete Processes.

Some options:

1. Add a new method to Process:  bool isContinuous().   
   Then Steppers can check the Process uses Variable::velocity.
   But basically it is Process writers' job to set this flag correctly.

2. Create base classes for each (such as DiscreteProcess and 
   ContinuousProcess).   The result is almost the same as option (1).

3. Don't distinguish.  Let users make sure their models are correct.




To avoid confusion, this policy must be decided before version 3.2.


-sha

> yes, the recommendation of using BisectionREQProcess means 
> remaning of it to RapidEquilibrium, and elimination of old
> REQProcess.
> Currently, BisectionRapidEquilibriumProcess have not tested 
> enough. It should be tested and debugged before renaming.

Ok.   Please do some test on that, and let sakurada know
it is ready to be included in version 3.1.96, which will be
out around, hopefully, 7/1 or 7/2.


About your ideas below, I quite agree that it can have multiple ways
to solve the equilibrium equation.    But I'm not sure defining
a different class for each is useful.

Isn't it possible to have a single big class which adaptively switch
between algorithms?

It may check the number of reactants in initialize(), and decide
what algorithm to use.   Its implementation can be done by using
method pointers.  

See GillespieProcess.[ch]pp, it uses this technique.

On top of the class definition, define a method pointer type 
(RealMethodPtr in this case):

  typedef const Real (RapidEquilibriumProcess::* RealMethodPtr)() const;
  
Create a member variable.

  RealMethodPtr theEquilibriumMethodPtr;

Define some variations of the method:

    const Real simplemethod() const;
    const Real genericmethod() const;

And in initialize, adaptively set the pointer like this


  if( simple )
    {
      theEquilibriumMethodPtr = &RapidEquilibriumProcess::simplemethod;
    }
  else if( it needs generic algorithm )
    {
      theEquilibriumMethodPtr = &RapidEquilibriumProcess::genericmethod;
    }
  else if( ... )


Calling the method via the pointer is like this:

  Real aResult( ( this->*theGetMinValueMethodPtr )() );



Note that if it has only two variations, it is possible that 
simply switching between them every time in process() is faster.
(just a guess.  some benchmark is needed to verify this.)
This method would be effective if you have more than two variations.

-sha


> I'm also considering about another idea of EQ things.
> 
> In the case of that both numbers of product and substrate
> are less than two, analytical algorithm can be used to calculate
> rapid equilibrium reaction rate.
> The name of the Process will be "SimpleRapidEquilibriumProcess"
> or something.
> To implement and test it, we need more half a day.
> 
> Based on the same idea, "MultipleRapidEquilibriumProcess" can be 
> desigend. It is for more than two rapid EQ reactions which have to be
> solved together. The Process will be limited to reactions with
> less than two reactants. It will be based on a numerical algorithm.
> It maybe takes one day to implement and test.
> 
> 
> I think we need feasible GeneralRapidEquilibriumProcess.
> It is for more than two rapid EQ reactions, and the number of 
> reactants of each reactions are not limited.
> GeneralRapidEquilibriumReactor I developed is not good enough.
> Does anyone work for that?
> 

thanks kem,


As for equilibrium calculation in general,  the way how ecell1 and
current ecell3 solves it is an explicit solution.   That means,
it is a two-step procedure.

1. solve ODE explicitly (such as forward-runge kutta)
2. solve algebraic equation *iteratively*

(iteratively means it must use some nonlinear optimization 
 technique to find the solution)


Another way, which is believed to be more sophisticated, is to use
implicit ODE solver.

1. solve ODE and algebraic equations at the same time *iteratively*
   (such as implicit runge-kutta and backward-euler)


Kaizu is now working on development of the implicit solver. 
E-Cell 3 will have a 'true' DAE solver.

Still providing the RapidEquilibriumProcess is very important.
Explicit modeling is sometimes very useful.  


I decided to use explicit way when I designed ecell1 because
using implicit solvers can put some limitations to ecell's modeling
scheme. For example, using difference equations, which is often 
used in ecell (such as FDA-ODE hybrid simulation).   

However, E-Cell 3 became a multi-Stepper simulator.   Its model
can be divided into parts, and different simulation algorithms can 
be adopted for each.  If only one Stepper can be there, it is safe to
provide just one most generic algorithm.  But multi-Stepper is allowed,
it makes sense to give choices, for example, between more efficient and
less generic implicit solver, and less efficient and more generic
explicit solvers.


I'll write again about the RapidEquilibriumProcess.


-sha

> I haven't known BisectionREQProcess is already on the CVS,
> because I use ecell-3.1.95.
> 
> yes, the recommendation of using BisectionREQProcess means 
> remaning of it to RapidEquilibrium, and elimination of old
> REQProcess.
> Currently, BisectionRapidEquilibriumProcess have not tested 
> enough. It should be tested and debugged before renaming.
> 
> it's great for me to work with Tomo. the test and debugging
> will be half-day task.
> 
> 
> I'm also considering about another idea of EQ things.
> 
> In the case of that both numbers of product and substrate
> are less than two, analytical algorithm can be used to calculate
> rapid equilibrium reaction rate.
> The name of the Process will be "SimpleRapidEquilibriumProcess"
> or something.
> To implement and test it, we need more half a day.
> 
> Based on the same idea, "MultipleRapidEquilibriumProcess" can be 
> desigend. It is for more than two rapid EQ reactions which have to be
> solved together. The Process will be limited to reactions with
> less than two reactants. It will be based on a numerical algorithm.
> It maybe takes one day to implement and test.
> 
> 
> I think we need feasible GeneralRapidEquilibriumProcess.
> It is for more than two rapid EQ reactions, and the number of 
> reactants of each reactions are not limited.
> GeneralRapidEquilibriumReactor I developed is not good enough.
> Does anyone work for that?
> 
> 
> Kouichi Takahashi wrote:
> > BisectionRapidEquilibriumProcess is already on the CVS.
> > 
> > Does this mean a simple renaming of BisectionRapidEquilibrium to
> > RapidEquilibrium ok?
> > 
> > 
> > Tomo, I think you have worked on this before.   Can you work with kem
> > again?
> > 
> > 
> > -sha
> > 
> > 
> > 
> > 
> >>I found some bugs in RapidEquilibriumProcess.cpp .
> >>It confuses users who need to model equilibrium process.
> >>
> >>* Value of Keq is different from the one which user want to define, and
> >> it changes in one simulation
> >>  - Keq is redefined using own value in initialize() althouth initialize()
> >>    is called more than once in a simulation.
> >>
> >>* velocity is always set to 0. 
> >>
> >>I suggest that RapidEquilibriumProcess will be replaced, 
> >>because:
> >>
> >>  An alogrithm of RapidEquilibriumProcess (which I made) is not suitable
> >>  for generic simulation. It is only suitable for a simulation using integer
> >>  Valuables (like quantity of molecules).
> >>
> >>  A souce code of RapidEquilibriumProcess is not easy to read. It is like 
> >>  spagetti-code. It is worthless to spare long time to debug it.
> >>
> >>I have made a process called "BisectionalRapidEquilibriumProcess" which is 
> >>in ecoli/models/DM directory of internal CVS repository.
> >>It still has little bugs, but is easier to be debugged than old REQProcess.
> >>I'm happy if the Process is adopted.
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: INetU
> >>Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> >>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> >>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> >>_______________________________________________
> >>Ecell-devel mailing list
> >>Ece...@li...
> >>https://lists.sourceforge.net/lists/listinfo/ecell-devel
> >>
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> > _______________________________________________
> > Ecell-devel mailing list
> > Ece...@li...
> > https://lists.sourceforge.net/lists/listinfo/ecell-devel
> > 
> > 
> 
> 

removed ece...@bi...



> It seems that em2eml and eml2em have been removed from CVS ecell3/bin 
> directory. But no changes have been made to the configure, so it will 
> give a configure error. Would anyone modify the configure file?

This problem is fixed.   Let me know if it persists.


-sha

I haven't known BisectionREQProcess is already on the CVS,
because I use ecell-3.1.95.

yes, the recommendation of using BisectionREQProcess means 
remaning of it to RapidEquilibrium, and elimination of old
REQProcess.
Currently, BisectionRapidEquilibriumProcess have not tested 
enough. It should be tested and debugged before renaming.

it's great for me to work with Tomo. the test and debugging
will be half-day task.


I'm also considering about another idea of EQ things.

In the case of that both numbers of product and substrate
are less than two, analytical algorithm can be used to calculate
rapid equilibrium reaction rate.
The name of the Process will be "SimpleRapidEquilibriumProcess"
or something.
To implement and test it, we need more half a day.

Based on the same idea, "MultipleRapidEquilibriumProcess" can be 
desigend. It is for more than two rapid EQ reactions which have to be
solved together. The Process will be limited to reactions with
less than two reactants. It will be based on a numerical algorithm.
It maybe takes one day to implement and test.


I think we need feasible GeneralRapidEquilibriumProcess.
It is for more than two rapid EQ reactions, and the number of 
reactants of each reactions are not limited.
GeneralRapidEquilibriumReactor I developed is not good enough.
Does anyone work for that?


Kouichi Takahashi wrote:
> BisectionRapidEquilibriumProcess is already on the CVS.
> 
> Does this mean a simple renaming of BisectionRapidEquilibrium to
> RapidEquilibrium ok?
> 
> 
> Tomo, I think you have worked on this before.   Can you work with kem
> again?
> 
> 
> -sha
> 
> 
> 
> 
>>I found some bugs in RapidEquilibriumProcess.cpp .
>>It confuses users who need to model equilibrium process.
>>
>>* Value of Keq is different from the one which user want to define, and
>> it changes in one simulation
>>  - Keq is redefined using own value in initialize() althouth initialize()
>>    is called more than once in a simulation.
>>
>>* velocity is always set to 0. 
>>
>>I suggest that RapidEquilibriumProcess will be replaced, 
>>because:
>>
>>  An alogrithm of RapidEquilibriumProcess (which I made) is not suitable
>>  for generic simulation. It is only suitable for a simulation using integer
>>  Valuables (like quantity of molecules).
>>
>>  A souce code of RapidEquilibriumProcess is not easy to read. It is like 
>>  spagetti-code. It is worthless to spare long time to debug it.
>>
>>I have made a process called "BisectionalRapidEquilibriumProcess" which is 
>>in ecoli/models/DM directory of internal CVS repository.
>>It still has little bugs, but is easier to be debugged than old REQProcess.
>>I'm happy if the Process is adopted.
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: INetU
>>Attention Web Developers & Consultants: Become An INetU Hosting Partner.
>>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
>>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>>_______________________________________________
>>Ecell-devel mailing list
>>Ece...@li...
>>https://lists.sourceforge.net/lists/listinfo/ecell-devel
>>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 
> 

It's been two months since the last release of 3.1.95.

To facilitate collaborative development and to let users updated,
I think we need to release 3.1.96 now.

Make a snapshot release now, as soon as when zak and maru, who
make RPMs, are ready.

If any of you have something that need to be included in the
new release, let me know soon.


I decided to delay the release of 3.1.96 last month because we found 
the bug in ODE Steppers that amplifies error.   Kaizu had identified 
the problem and now creating a patch, but we were too busy this month.
(I'm working on my thesis, and we also had a conference)
The patch is not yet ready, but making a release, even without it, 
is necessary.    The bug can be worked around by running the simulation
without interrupting.  The calculation error occurs when it stops and
re-run.


-sha

BisectionRapidEquilibriumProcess is already on the CVS.

Does this mean a simple renaming of BisectionRapidEquilibrium to
RapidEquilibrium ok?


Tomo, I think you have worked on this before.   Can you work with kem
again?


-sha



> I found some bugs in RapidEquilibriumProcess.cpp .
> It confuses users who need to model equilibrium process.
> 
> * Value of Keq is different from the one which user want to define, and
>  it changes in one simulation
>   - Keq is redefined using own value in initialize() althouth initialize()
>     is called more than once in a simulation.
> 
> * velocity is always set to 0. 
> 
> I suggest that RapidEquilibriumProcess will be replaced, 
> because:
> 
>   An alogrithm of RapidEquilibriumProcess (which I made) is not suitable
>   for generic simulation. It is only suitable for a simulation using integer
>   Valuables (like quantity of molecules).
> 
>   A souce code of RapidEquilibriumProcess is not easy to read. It is like 
>   spagetti-code. It is worthless to spare long time to debug it.
> 
> I have made a process called "BisectionalRapidEquilibriumProcess" which is 
> in ecoli/models/DM directory of internal CVS repository.
> It still has little bugs, but is easier to be debugged than old REQProcess.
> I'm happy if the Process is adopted.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 

good news, 
the latest rawhide of redhat now carries boost-1.30.
This would be shipped with the next release of redhat 
distribution (redhat-9.1 or redhat-10?)


One good result of this is that inclusion of the boost package
in src.rpm and binary rpms would no longer be necessary.

Another implication is now we can make full use of the boost library.
Currently the use of boost is restricted to boost python library in 
pyecs and PythonProcess.   We will be able to assume that all header 
files and library archives of boost is installed on the system, so
we will be able to use it in other parts of the system such as libecs
and DMs.


-sha

hi again,


The CVS version now has complete DiscreteEventStepper and
DiscreteEventProcess classes for discrete event simulation.

By this change, now the NRStepper is a subclass of the
DiscreteEventStepper, and GillespieProcess inherits
DiscreteEventProcess.    

Gillespie-Gibson's Next Reaction (NR) method is actually a fairly
straightforward discrete event simulation algorithm.   Thus NRStepper
actually is not different from its base class.  Now it's a dummy to keep
compatibility.   You can use DiscreteEventStepper instead of NRStepper.
Of course it is possible that NRStepper would get some special features
those differentiate it from its base class.   So keep using NRStepper 
if you prefer to do so.


-sha

hi,


I have made some optimizations to make discrete Steppers run
faster.     Now hubin's heat-shock model (earlier version)
runs 30-40% faster than before in pure-stochastic mode.

This optimization omits calling Variable::integrate(), if the
Variable is purely discrete (i.e. no continuous Stepper is 
connected with it).

Another part I tweaked is the scheduler.  DynamicPriorityQueue class
created by a former tomita-ken student, Adachi, is used both in the
main global scheduler of libecs, and the Gillespie-Gibson implementation.
Especially changeOneKey(), goUp(), and goDown() methods consumes
CPU power in Gillespie simulation if the number of reactions is large.
I have tuned it by inspecting resulting assembly, and it now emits
20-30% less x86 instructions.    I think it can be tuned even more.
I'll leave this for Satya:)  He is going to make a major reconstruction of 
the code for his parallel implementation.


This optimization won't affect performance of continuous differential
Steppers.


-sha

Now the CVS version has these new methods:

- Variable::getMolarConc()  - concentration in value / ( SIZE * Avogadro)
- Variable::getNumberConc() - concentration in value / SIZE


It still has the older method:

- Variable::getConcentration()  - an alias to getMoarConc()

but this will be deprecated before version 3.2.


-sha



> > I agree the former idea because two ways for definition of 
> > similar (but not same) value makes us confuse.
> > I think getMolarConc() is easier to understand.
> 
> Tom also personally suggested getMolarConcentration() and
> getNumberConcentration().
> 
> Well then,
> 
> - getConc()              -- getValue() / SIZE
> - getMolarConc()         -- getValue() / ( SIZE * Avogadro )
> 
> 
> ?   Here getConcentration() is deprecated to notify users this change.
> Or, older models run to give wrong results without an error.
> 
> 
> -sha
> 
> 
> 
> 
> 
> 
> 
> > Kouichi Takahashi wrote:
> > >>To summarize, the proposal is to change the method set like this:
> > >>
> > >>- getConcentration() returns value / SIZE of the compartment  --> typically # per liter
> > >>- getMole() returns value / Avogadro number   --> Mole
> > >>- getMolar() returns getMole() / SIZE                 -->  Molar concentration
> > > 
> > > 
> > > Another (I think better) possibility may be:
> > > 
> > > - getConcentration()   -> Molar concentration (no change, backward-compatible)
> > > - getMole()                -> Mole
> > > - getDensity()              -> value / SIZE
> > > 
> > > 
> > > Does anyone have objection to this proposal?
> > > 
> > > - sha
> > > 
> > > 
> > > 
> > >>I'm now thinking about changing the behavior of Variable::getConcentration() method,
> > >>and creating a new method Variable::getMolar().
> > >>
> > >>Currently:
> > >>
> > >>-  getConcentration() returns Molar ( mole / liter )
> > >>
> > >>It makes sense mainly in chemical and biochemical simulations.
> > >>
> > >>However, considering ecell is taking a way for a generic simulator, I think it is
> > >>better to define the behavior of the method as just:
> > >>
> > >>- getConcentration() returns value / SIZE of the compartment.
> > >>
> > >>For example, if the dimension of the compartment is 2, the dimension of the SIZE
> > >>is area.    The new definition still works in this case: value / SIZE (area) of the compartment.
> > >>If the value means the number of particles (or molecules), then it means average 
> > >>density of the particles on the surface.
> > >>
> > >>
> > >>Instead, for biochemical simulations, I'm thinking about adding a new method getMolar().
> > >>The name can also be:  getM(), getMolarity(), getMolarConcentration(), or getMolarConc(),
> > >>but currently I'm considering getMolar() as the primary condidate.
> > >>
> > >>Also, getMole() can be useful.
> > >>
> > >>To summarize, the proposal is to change the method set like this:
> > >>
> > >>- getConcentration() returns value / SIZE of the compartment  --> typically # per liter
> > >>- getMole() returns value / Avogadro number   --> Mole
> > >>- getMolar() returns getMole() / SIZE                 -->  Molar concentration
> > >>
> > >>
> > >>If this change is approved, all existing models must be checked and modified, but
> > >>if we are to take this, I think it is better to do it before version 3.2.
> > >>
> > >>
> > >>Any comment / suggestion / objection is welcome.
> > >>
> > >>-sha
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>-------------------------------------------------------
> > >>This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> > >>thread debugger on the planet. Designed with thread debugging features
> > >>you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > >>_______________________________________________
> > >>Ecell-devel mailing list
> > >>Ece...@li...
> > >>https://lists.sourceforge.net/lists/listinfo/ecell-devel
> > >>
> > > 
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: INetU
> > > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > > _______________________________________________
> > > Ecell-devel mailing list
> > > Ece...@li...
> > > https://lists.sourceforge.net/lists/listinfo/ecell-devel
> > > 
> > > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > _______________________________________________
> > Ecell-devel mailing list
> > Ece...@li...
> > https://lists.sourceforge.net/lists/listinfo/ecell-devel
> > 
> 
> 

I found some bugs in RapidEquilibriumProcess.cpp .
It confuses users who need to model equilibrium process.

* Value of Keq is different from the one which user want to define, and
 it changes in one simulation
  - Keq is redefined using own value in initialize() althouth initialize()
    is called more than once in a simulation.

* velocity is always set to 0. 

I suggest that RapidEquilibriumProcess will be replaced, 
because:

  An alogrithm of RapidEquilibriumProcess (which I made) is not suitable
  for generic simulation. It is only suitable for a simulation using integer
  Valuables (like quantity of molecules).

  A souce code of RapidEquilibriumProcess is not easy to read. It is like 
  spagetti-code. It is worthless to spare long time to debug it.

I have made a process called "BisectionalRapidEquilibriumProcess" which is 
in ecoli/models/DM directory of internal CVS repository.
It still has little bugs, but is easier to be debugged than old REQProcess.
I'm happy if the Process is adopted.

hi yoyo,


> Is the syntax for "BoundaryProcess.cpp",
> a Process that doesn't require any properties, correct?


You may almost always want to inherit those from the base class
(Process).


> When I try to load my model(and fail),
> I receive the following message.
> 
> RuntimeError: DMException: Failed to find or load a DM
> [BoundaryProcess]: BoundaryProcess.so: undefined symbol:
> _ZN15BoundaryProcess20initializePropertiesIS_EEvN6libecs9Type2TypeIT_EE

LIBECS_DM_OBJECT() must have the pair of {}s even if there is no property
to be defined.  Or the system fails to find that property table. (above error)

> 
> ______________________________________________________________________
> #include "libecs.hpp"
> #include "Process.hpp"

> USE_LIBECS;
> 
> LIBECS_DM_CLASS( BoundaryProcess, Process )
> {
> 
>  public:
> 
>   LIBECS_DM_OBJECT( BoundaryProcess, Process );
    {
      INHERIT_PROPERTIES( Process );

    }  

>   BoundaryProcess()
>     {
>       ; // do nothing
>     }
>   
>   virtual void initialize()
>     {
>       Process::initialize();
>       E0 = getVariableReference( "E0" );
>       P0 = getVariableReference( "P0" );  
>     }
> 
>   virtual void process()
>     {
        const Real Effector0( E0.getValue() ;
        P0.setValue( Effector0 );
>     }
> 
>  protected:
>   
>   VariableReference E0;
>   VariableReference P0;
>   
> };
> 
> LIBECS_DM_INIT( BoundaryProcess, Process );

I was able to solve the following problem :-)

yoyo

Yohei Yamada wrote:

>Hi.
>
>Is the syntax for "BoundaryProcess.cpp",
>a Process that doesn't require any properties, correct?
>
>When I try to load my model(and fail),
>I receive the following message.
>
>RuntimeError: DMException: Failed to find or load a DM
>[BoundaryProcess]: BoundaryProcess.so: undefined symbol:
>_ZN15BoundaryProcess20initializePropertiesIS_EEvN6libecs9Type2TypeIT_EE
>
>Thanks,
>
>yoyo
>  
>

Hi.

Is the syntax for "BoundaryProcess.cpp",
a Process that doesn't require any properties, correct?

When I try to load my model(and fail),
I receive the following message.

RuntimeError: DMException: Failed to find or load a DM
[BoundaryProcess]: BoundaryProcess.so: undefined symbol:
_ZN15BoundaryProcess20initializePropertiesIS_EEvN6libecs9Type2TypeIT_EE

Thanks,

yoyo

Kem,


> I agree the former idea because two ways for definition of 
> similar (but not same) value makes us confuse.
> I think getMolarConc() is easier to understand.

Tom also personally suggested getMolarConcentration() and
getNumberConcentration().

Well then,

- getConc()              -- getValue() / SIZE
- getMolarConc()         -- getValue() / ( SIZE * Avogadro )


?   Here getConcentration() is deprecated to notify users this change.
Or, older models run to give wrong results without an error.


-sha







> Kouichi Takahashi wrote:
> >>To summarize, the proposal is to change the method set like this:
> >>
> >>- getConcentration() returns value / SIZE of the compartment  --> typically # per liter
> >>- getMole() returns value / Avogadro number   --> Mole
> >>- getMolar() returns getMole() / SIZE                 -->  Molar concentration
> > 
> > 
> > Another (I think better) possibility may be:
> > 
> > - getConcentration()   -> Molar concentration (no change, backward-compatible)
> > - getMole()                -> Mole
> > - getDensity()              -> value / SIZE
> > 
> > 
> > Does anyone have objection to this proposal?
> > 
> > - sha
> > 
> > 
> > 
> >>I'm now thinking about changing the behavior of Variable::getConcentration() method,
> >>and creating a new method Variable::getMolar().
> >>
> >>Currently:
> >>
> >>-  getConcentration() returns Molar ( mole / liter )
> >>
> >>It makes sense mainly in chemical and biochemical simulations.
> >>
> >>However, considering ecell is taking a way for a generic simulator, I think it is
> >>better to define the behavior of the method as just:
> >>
> >>- getConcentration() returns value / SIZE of the compartment.
> >>
> >>For example, if the dimension of the compartment is 2, the dimension of the SIZE
> >>is area.    The new definition still works in this case: value / SIZE (area) of the compartment.
> >>If the value means the number of particles (or molecules), then it means average 
> >>density of the particles on the surface.
> >>
> >>
> >>Instead, for biochemical simulations, I'm thinking about adding a new method getMolar().
> >>The name can also be:  getM(), getMolarity(), getMolarConcentration(), or getMolarConc(),
> >>but currently I'm considering getMolar() as the primary condidate.
> >>
> >>Also, getMole() can be useful.
> >>
> >>To summarize, the proposal is to change the method set like this:
> >>
> >>- getConcentration() returns value / SIZE of the compartment  --> typically # per liter
> >>- getMole() returns value / Avogadro number   --> Mole
> >>- getMolar() returns getMole() / SIZE                 -->  Molar concentration
> >>
> >>
> >>If this change is approved, all existing models must be checked and modified, but
> >>if we are to take this, I think it is better to do it before version 3.2.
> >>
> >>
> >>Any comment / suggestion / objection is welcome.
> >>
> >>-sha
> >>
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> >>thread debugger on the planet. Designed with thread debugging features
> >>you've never dreamed of, try TotalView 6 free at www.etnus.com.
> >>_______________________________________________
> >>Ecell-devel mailing list
> >>Ece...@li...
> >>https://lists.sourceforge.net/lists/listinfo/ecell-devel
> >>
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > _______________________________________________
> > Ecell-devel mailing list
> > Ece...@li...
> > https://lists.sourceforge.net/lists/listinfo/ecell-devel
> > 
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 

Hi Shafi.

I agree the former idea because two ways for definition of 
similar (but not same) value makes us confuse.
I think getMolarConc() is easier to understand.


Kouichi Takahashi wrote:
>>To summarize, the proposal is to change the method set like this:
>>
>>- getConcentration() returns value / SIZE of the compartment  --> typically # per liter
>>- getMole() returns value / Avogadro number   --> Mole
>>- getMolar() returns getMole() / SIZE                 -->  Molar concentration
> 
> 
> Another (I think better) possibility may be:
> 
> - getConcentration()   -> Molar concentration (no change, backward-compatible)
> - getMole()                -> Mole
> - getDensity()              -> value / SIZE
> 
> 
> Does anyone have objection to this proposal?
> 
> - sha
> 
> 
> 
>>I'm now thinking about changing the behavior of Variable::getConcentration() method,
>>and creating a new method Variable::getMolar().
>>
>>Currently:
>>
>>-  getConcentration() returns Molar ( mole / liter )
>>
>>It makes sense mainly in chemical and biochemical simulations.
>>
>>However, considering ecell is taking a way for a generic simulator, I think it is
>>better to define the behavior of the method as just:
>>
>>- getConcentration() returns value / SIZE of the compartment.
>>
>>For example, if the dimension of the compartment is 2, the dimension of the SIZE
>>is area.    The new definition still works in this case: value / SIZE (area) of the compartment.
>>If the value means the number of particles (or molecules), then it means average 
>>density of the particles on the surface.
>>
>>
>>Instead, for biochemical simulations, I'm thinking about adding a new method getMolar().
>>The name can also be:  getM(), getMolarity(), getMolarConcentration(), or getMolarConc(),
>>but currently I'm considering getMolar() as the primary condidate.
>>
>>Also, getMole() can be useful.
>>
>>To summarize, the proposal is to change the method set like this:
>>
>>- getConcentration() returns value / SIZE of the compartment  --> typically # per liter
>>- getMole() returns value / Avogadro number   --> Mole
>>- getMolar() returns getMole() / SIZE                 -->  Molar concentration
>>
>>
>>If this change is approved, all existing models must be checked and modified, but
>>if we are to take this, I think it is better to do it before version 3.2.
>>
>>
>>Any comment / suggestion / objection is welcome.
>>
>>-sha
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
>>thread debugger on the planet. Designed with thread debugging features
>>you've never dreamed of, try TotalView 6 free at www.etnus.com.
>>_______________________________________________
>>Ecell-devel mailing list
>>Ece...@li...
>>https://lists.sourceforge.net/lists/listinfo/ecell-devel
>>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 
> 

Hi,

Regarding the attached change of having SIZE Variable instead of 
System::Volume proposed in the previous message,  these two classes
were deprecated.

- CompartmentSystem
- VirtualSystem

Instead, the CompartmentSystem was renamed to just System.

For backward compatibility, 'CompartmentSystem' is an alias of 'System'.
Thus no change is required in EM files for the time being.


Let me know if you experience any problem.

-sha




> hi people,
> 
> I hope this is the last big change before version 3.2.
> 
> On the CVS version I have changed the name of System::Volume to System::SIZE, and
> made it a Variable, instead of a property of System.
> 
> Which means, if you want to specify a size (volume) of a System,  you need to 
> write like this:
> 
> System CompartmentSystem( /SOME/COMPARTMENT )
> {
> 	Variable Variable( SIZE )
>         {
> 		Value 1e-18;
>         }
> }
> 
> 
> Specs:
> 
> - In C++, System::getVolume() and System::getVolumeN_A() methods were renamed to,
>   getSize() and getSizeN_A().
> 
> - In C++, System::setVolume() method has been deprecated.
>   Instead, the SIZE must be treated as a Variable that can be changed by Process objects.
> 
> - Similarly, in PythonProcess, System.Volume has been renamed to System.Size
> 
> - If a System has no 'SIZE' Variable, and the SIZE is requested (either by System::getSize() or
>   Variable::getConcentration() ), then it returns SIZE of the supersystem.   
> 
> - The root system must have the SIZE Variable.  If it isn't given by a model file, then
>   the simulator creates it with Value 1, at the first time when initialize() is called.
> 
> 
> 
> RATIONALE:
> 
> The name was changed from Volume to Size because:
> 
> - Size is more generic, and can be used to specify 1D (length), 2D (area) and 3D(volume)
>   metrics of compartments.
> 
> - SBML standard is going to change its compartment attribute 'volume' to 'size', and to
>   add a new attribute 'dimension'
> 
> 
> It is better to be a Variable than a property because:
> 
> - if we have models with changing volumes, the volume must be treated as Variables, 
>   or error control in multi-stepper simulation via object dependency check cannot 
>   be done in an intuitive way.
> 
> 
> 
> 
> 
> All demo models under doc/samples were modified.
> 
> -sha
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 

> To summarize, the proposal is to change the method set like this:
> 
> - getConcentration() returns value / SIZE of the compartment  --> typically # per liter
> - getMole() returns value / Avogadro number   --> Mole
> - getMolar() returns getMole() / SIZE                 -->  Molar concentration

Another (I think better) possibility may be:

- getConcentration()   -> Molar concentration (no change, backward-compatible)
- getMole()                -> Mole
- getDensity()              -> value / SIZE


Does anyone have objection to this proposal?

- sha


> I'm now thinking about changing the behavior of Variable::getConcentration() method,
> and creating a new method Variable::getMolar().
> 
> Currently:
> 
> -  getConcentration() returns Molar ( mole / liter )
> 
> It makes sense mainly in chemical and biochemical simulations.
> 
> However, considering ecell is taking a way for a generic simulator, I think it is
> better to define the behavior of the method as just:
> 
> - getConcentration() returns value / SIZE of the compartment.
> 
> For example, if the dimension of the compartment is 2, the dimension of the SIZE
> is area.    The new definition still works in this case: value / SIZE (area) of the compartment.
> If the value means the number of particles (or molecules), then it means average 
> density of the particles on the surface.
> 
> 
> Instead, for biochemical simulations, I'm thinking about adding a new method getMolar().
> The name can also be:  getM(), getMolarity(), getMolarConcentration(), or getMolarConc(),
> but currently I'm considering getMolar() as the primary condidate.
> 
> Also, getMole() can be useful.
> 
> To summarize, the proposal is to change the method set like this:
> 
> - getConcentration() returns value / SIZE of the compartment  --> typically # per liter
> - getMole() returns value / Avogadro number   --> Mole
> - getMolar() returns getMole() / SIZE                 -->  Molar concentration
> 
> 
> If this change is approved, all existing models must be checked and modified, but
> if we are to take this, I think it is better to do it before version 3.2.
> 
> 
> Any comment / suggestion / objection is welcome.
> 
> -sha
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 

Hi,

>>Really you dont have a Debian mantainer? If so i can
>>try to make the deb pkg...
>>    
>>
>
>Although I heared from some people who tried to build the system on debian,
>as far as I know, we have no joy yet.   The problem I guess is not that of ecell3 itself,
>but that debian carries a bit older versions of packages; especially pygtk and gtk.
>It's great if you can make a .deb.
>
>  
>
I only used Debian for a not long time but isn't there a pkg called 
alian? I think that shall be able to make debian package from .rpm . 
 Maybe you would like to try this? For the debian distro users, 
pkg-update seems better than the RHN. So, actually debian users may have 
the latest packages available.

>  
>

Hi Ferdinando,

> Hi! I'm an italian  student of pharmaceutical chamistry next to the
> degree. I'd like to master the use of ecell sim env 3. I've yet read the
> user manual ad the design rationale reading. I plan to learn python this
> summer. 

Great to know you are going to use ecell3.
If you need a deeper understanding of numerics part of the system, tell me, 
I can send you some more reading materials.

> Now some questions for you =)
> I'm starting to understand how all this works, but still got some dubts,
> after having the *.em file how can i sim the evolution from that static
> model i wrote? I mean: suppose i've wrote a model of a genom starting
> point and i'd like to know if this situation can evolve to for example
> an interaction with a TF, an iper expression of a gene... This is
> obscure for me now. 

I couldn't get your question very well, but are you asking how to run your model
written in form of a .em file?   
If this is the question, it is simple:

First you have to create an EML file from your EM file.

% ecell3-em2eml your.em      # this creates your.eml file.

Then run the simulation either in GUI or scripting mode.

% gecell -f your.eml               # run it in GUI mode

or

% ecell3-session -f your.eml  # scripting mode


> Really you dont have a Debian mantainer? If so i can
> try to make the deb pkg...

Although I heared from some people who tried to build the system on debian,
as far as I know, we have no joy yet.   The problem I guess is not that of ecell3 itself,
but that debian carries a bit older versions of packages; especially pygtk and gtk.
It's great if you can make a .deb.


We are now going to release the next beta version 3.1.96, and that includes
some changes visible to users.   
If you don't mind to build it from sourcecode, I quite recommend to use the anonymous
CVS to get the source code before the release.    I'll update the manual for the new version
when it is released, but you can get the latest version under doc/users_manual/ directory
of the source distribution.

keep in touch!

-sha

P.S. If you are going to try to build it on debian, subscribe to ecell-devel (CC'd).   
       It's the best place to discuss about it and get the up-to-date information.

Thank you shafi.
I'm worried about macros which I created.
I will try to modify it to fit new syntax after three weeks.
Perhaps, I will ask your advice at that time.
Until then, I use the version 3.1.95 .

If you want to know about my macro files right now to consider about some
peculiar model description, please get files from the internal CVS 
repository. the directory is ecoli/models/include and ecoli/models/GX.

thanks.

Kouichi Takahashi wrote:
> Kem,
> 
> 
> 
>>You mean all modeler's original Processes must be modified to fit new syntax?
>>Or, the syntax is additional and the Processes need not to be changed?
> 
> 
> Yes you need to modify your DMs for the CVS version.   This change will be
> included in the version 3.1.96.
> 
> I had a choice between to do this now or after version 3.3.    And because this change
> is inevitable in certain point in time, I thought it is better to change it right now, before version 
> 3.2, when the number of users will increase very much. 
> This will never happen after 3.2, at least before 3.3.
> 
> How many DMs do you have?    If you find it difficult send me some and I'll show you how.
> 
> 
> -sha
> 
> 
> 
> 
> 
>>Kouichi Takahashi wrote:
>>
>>>Hi all,
>>>
>>>I have uploaded a big patch on the CVS.
>>>
>>>This doesn't change behavior of the frontend API,  but those who write DMs by their own
>>>need to catch up with the new syntax.
>>>
>>>This patch drastically reduces memory consumption of ecell3 especially in 
>>>very large models.    (In very small models it is the same, or sometimes worse.  So
>>>this can be viewed as an optimization targeted for large models.)
>>>Previously the table of property names and method pointers
>>>(PropertySlotMap) was created for each object.   This posed a severe limitation of
>>>the system in large scale simulation models.  For example, previously 
>>>Tomo's 100x100 automata model required several hundred mega-bytes of memory.
>>>Now the PropertySlotMap is created for each class, and decreases the usage of the memory. 
>>>
>>>Also, the data logging mechanism has been slightly changed
>>>by introducing LoggerAdapter class.   Although this doesn't immediately present a benefit
>>>to end users,  now the design is generalized to make it possible to log data on
>>>other objects than Entities.
>>>
>>>This change was originally intended for version 3.3, but since it may take some more
>>>time to release the 3.2, I have decided to do at this time.    If the specification change
>>>is expected to occur, earlier the better.
>>>
>>>
>>>The manual is updated on the CVS (not on the web, because this is not included in 
>>>the official release yet.),  but here is a summary of the change:
>>>
>>>
>>>LIBECS_DM_CLASS( CLASSNAME, BASECLASS )   // (1) Always use  this macro.
>>>{
>>>public:
>>>
>>>  LIBECS_DM_OBJECT( CLASSNAME, DMTYPE )  // (2) Property definitions must be here.
>>>  {
>>>     INHERIT_PROPERTIES( BASECLASS );      //  (3) This is needed if properties of the base
>>>                                                                           //        class may be used.
>>>
>>>     PROPERTY_SET_GET( NAME, TYPE );        // (4) CREATE_PROPERTY_ was changed to
>>>                                                                            //       just 'PROPERTY_'
>>>                                                                           //  (5) CLASSNAME here is no longer needed:
>>>                                                                           //        which means just ( NAME, TYPE ) not
>>>                                                                           //        ( NAME, TYPE, CLASSNAME )
>>>     PROPERTY( NAME, TYPE, SET, GET );
>>>  }
>>>
>>>  CLASSNAME() 
>>>  {
>>>     // Don't place property definitions here.
>>>  }
>>>
>>>  ~CLASSNAME() {}
>>>
>>>};
>>>
>>>LIBECS_DM_INIT( CLASSNAME, DMTYPE );  // (6) Use this macro instead of DM_INIT().
>>>                                                                       // (7) The order of arguments has been changed:
>>>                                                                       //       ( CLASSNAME, DMTYPE ),
>>>                                                                       //       not ( DMTYPE, CLASSNAME )
>>>                                    
>>>
>>>All the sample models are modified.
>>>
>>>
>>>-sha
>>>
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.NET email is sponsored by: eBay
>>>Great deals on office technology -- on eBay now! Click here:
>>>http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
>>>_______________________________________________
>>>Ecell-devel mailing list
>>>Ece...@li...
>>>https://lists.sourceforge.net/lists/listinfo/ecell-devel
>>>
>>>
>>
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 
> 

Kem,


> You mean all modeler's original Processes must be modified to fit new syntax?
> Or, the syntax is additional and the Processes need not to be changed?

Yes you need to modify your DMs for the CVS version.   This change will be
included in the version 3.1.96.

I had a choice between to do this now or after version 3.3.    And because this change
is inevitable in certain point in time, I thought it is better to change it right now, before version 
3.2, when the number of users will increase very much. 
This will never happen after 3.2, at least before 3.3.

How many DMs do you have?    If you find it difficult send me some and I'll show you how.


-sha




> Kouichi Takahashi wrote:
> > Hi all,
> > 
> > I have uploaded a big patch on the CVS.
> > 
> > This doesn't change behavior of the frontend API,  but those who write DMs by their own
> > need to catch up with the new syntax.
> > 
> > This patch drastically reduces memory consumption of ecell3 especially in 
> > very large models.    (In very small models it is the same, or sometimes worse.  So
> > this can be viewed as an optimization targeted for large models.)
> > Previously the table of property names and method pointers
> > (PropertySlotMap) was created for each object.   This posed a severe limitation of
> > the system in large scale simulation models.  For example, previously 
> > Tomo's 100x100 automata model required several hundred mega-bytes of memory.
> > Now the PropertySlotMap is created for each class, and decreases the usage of the memory. 
> > 
> > Also, the data logging mechanism has been slightly changed
> > by introducing LoggerAdapter class.   Although this doesn't immediately present a benefit
> > to end users,  now the design is generalized to make it possible to log data on
> > other objects than Entities.
> > 
> > This change was originally intended for version 3.3, but since it may take some more
> > time to release the 3.2, I have decided to do at this time.    If the specification change
> > is expected to occur, earlier the better.
> > 
> > 
> > The manual is updated on the CVS (not on the web, because this is not included in 
> > the official release yet.),  but here is a summary of the change:
> > 
> > 
> > LIBECS_DM_CLASS( CLASSNAME, BASECLASS )   // (1) Always use  this macro.
> > {
> > public:
> > 
> >   LIBECS_DM_OBJECT( CLASSNAME, DMTYPE )  // (2) Property definitions must be here.
> >   {
> >      INHERIT_PROPERTIES( BASECLASS );      //  (3) This is needed if properties of the base
> >                                                                            //        class may be used.
> > 
> >      PROPERTY_SET_GET( NAME, TYPE );        // (4) CREATE_PROPERTY_ was changed to
> >                                                                             //       just 'PROPERTY_'
> >                                                                            //  (5) CLASSNAME here is no longer needed:
> >                                                                            //        which means just ( NAME, TYPE ) not
> >                                                                            //        ( NAME, TYPE, CLASSNAME )
> >      PROPERTY( NAME, TYPE, SET, GET );
> >   }
> > 
> >   CLASSNAME() 
> >   {
> >      // Don't place property definitions here.
> >   }
> > 
> >   ~CLASSNAME() {}
> > 
> > };
> > 
> > LIBECS_DM_INIT( CLASSNAME, DMTYPE );  // (6) Use this macro instead of DM_INIT().
> >                                                                        // (7) The order of arguments has been changed:
> >                                                                        //       ( CLASSNAME, DMTYPE ),
> >                                                                        //       not ( DMTYPE, CLASSNAME )
> >                                     
> > 
> > All the sample models are modified.
> > 
> > 
> > -sha
> > 
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.NET email is sponsored by: eBay
> > Great deals on office technology -- on eBay now! Click here:
> > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > _______________________________________________
> > Ecell-devel mailing list
> > Ece...@li...
> > https://lists.sourceforge.net/lists/listinfo/ecell-devel
> > 
> > 
> 
> 

Hi Shafi.

You mean all modeler's original Processes must be modified to fit new syntax?
Or, the syntax is additional and the Processes need not to be changed?


Kouichi Takahashi wrote:
> Hi all,
> 
> I have uploaded a big patch on the CVS.
> 
> This doesn't change behavior of the frontend API,  but those who write DMs by their own
> need to catch up with the new syntax.
> 
> This patch drastically reduces memory consumption of ecell3 especially in 
> very large models.    (In very small models it is the same, or sometimes worse.  So
> this can be viewed as an optimization targeted for large models.)
> Previously the table of property names and method pointers
> (PropertySlotMap) was created for each object.   This posed a severe limitation of
> the system in large scale simulation models.  For example, previously 
> Tomo's 100x100 automata model required several hundred mega-bytes of memory.
> Now the PropertySlotMap is created for each class, and decreases the usage of the memory. 
> 
> Also, the data logging mechanism has been slightly changed
> by introducing LoggerAdapter class.   Although this doesn't immediately present a benefit
> to end users,  now the design is generalized to make it possible to log data on
> other objects than Entities.
> 
> This change was originally intended for version 3.3, but since it may take some more
> time to release the 3.2, I have decided to do at this time.    If the specification change
> is expected to occur, earlier the better.
> 
> 
> The manual is updated on the CVS (not on the web, because this is not included in 
> the official release yet.),  but here is a summary of the change:
> 
> 
> LIBECS_DM_CLASS( CLASSNAME, BASECLASS )   // (1) Always use  this macro.
> {
> public:
> 
>   LIBECS_DM_OBJECT( CLASSNAME, DMTYPE )  // (2) Property definitions must be here.
>   {
>      INHERIT_PROPERTIES( BASECLASS );      //  (3) This is needed if properties of the base
>                                                                            //        class may be used.
> 
>      PROPERTY_SET_GET( NAME, TYPE );        // (4) CREATE_PROPERTY_ was changed to
>                                                                             //       just 'PROPERTY_'
>                                                                            //  (5) CLASSNAME here is no longer needed:
>                                                                            //        which means just ( NAME, TYPE ) not
>                                                                            //        ( NAME, TYPE, CLASSNAME )
>      PROPERTY( NAME, TYPE, SET, GET );
>   }
> 
>   CLASSNAME() 
>   {
>      // Don't place property definitions here.
>   }
> 
>   ~CLASSNAME() {}
> 
> };
> 
> LIBECS_DM_INIT( CLASSNAME, DMTYPE );  // (6) Use this macro instead of DM_INIT().
>                                                                        // (7) The order of arguments has been changed:
>                                                                        //       ( CLASSNAME, DMTYPE ),
>                                                                        //       not ( DMTYPE, CLASSNAME )
>                                     
> 
> All the sample models are modified.
> 
> 
> -sha
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 
> 

Hi all,

I have uploaded a big patch on the CVS.

This doesn't change behavior of the frontend API,  but those who write DMs by their own
need to catch up with the new syntax.

This patch drastically reduces memory consumption of ecell3 especially in 
very large models.    (In very small models it is the same, or sometimes worse.  So
this can be viewed as an optimization targeted for large models.)
Previously the table of property names and method pointers
(PropertySlotMap) was created for each object.   This posed a severe limitation of
the system in large scale simulation models.  For example, previously 
Tomo's 100x100 automata model required several hundred mega-bytes of memory.
Now the PropertySlotMap is created for each class, and decreases the usage of the memory. 

Also, the data logging mechanism has been slightly changed
by introducing LoggerAdapter class.   Although this doesn't immediately present a benefit
to end users,  now the design is generalized to make it possible to log data on
other objects than Entities.

This change was originally intended for version 3.3, but since it may take some more
time to release the 3.2, I have decided to do at this time.    If the specification change
is expected to occur, earlier the better.


The manual is updated on the CVS (not on the web, because this is not included in 
the official release yet.),  but here is a summary of the change:


LIBECS_DM_CLASS( CLASSNAME, BASECLASS )   // (1) Always use  this macro.
{
public:

  LIBECS_DM_OBJECT( CLASSNAME, DMTYPE )  // (2) Property definitions must be here.
  {
     INHERIT_PROPERTIES( BASECLASS );      //  (3) This is needed if properties of the base
                                                                           //        class may be used.

     PROPERTY_SET_GET( NAME, TYPE );        // (4) CREATE_PROPERTY_ was changed to
                                                                            //       just 'PROPERTY_'
                                                                           //  (5) CLASSNAME here is no longer needed:
                                                                           //        which means just ( NAME, TYPE ) not
                                                                           //        ( NAME, TYPE, CLASSNAME )
     PROPERTY( NAME, TYPE, SET, GET );
  }

  CLASSNAME() 
  {
     // Don't place property definitions here.
  }

  ~CLASSNAME() {}

};

LIBECS_DM_INIT( CLASSNAME, DMTYPE );  // (6) Use this macro instead of DM_INIT().
                                                                       // (7) The order of arguments has been changed:
                                                                       //       ( CLASSNAME, DMTYPE ),
                                                                       //       not ( DMTYPE, CLASSNAME )
                                    

All the sample models are modified.


-sha