ecell-devel Mailing List for E-Cell System

Hi all,

I have renamed ECS.py to ecs_constants.py because of filename conflict 
with ecs.py in Windows.

satya

hi ishidasan,

> Here is a comparison of usr times of FixdeODE1 runs:
> 
>             PythonFluxProcess    ExpressionFlux         Native(C++)
>                                                        Process    
> 100s       19.715s                   0.971s                    0.527s
> 1000s     193.830s                 7.689s                    3.531s
> 
> ExpressionFluxProcess is about 2 times slower than Native(C++). 
> But ExpressionFluxProcess is much faster than PythonFluxProcess. 
> ( about 25 times faster )

Excellent!    With this performance level it can replace
C++ Processes in many cases.

I have been thinking about using a kind of JIT and/or register virtual
machine to boost this even more, in cases I couldn't get a satisfiable
performance by the current virtual stack machine implementation, but
considering that your implementation runs quite fast, and  we do not
have a good general-purpose opensource JIT available yet, it will be in
service for a while (some years).   

I have browsed the code, and found some parts that awaits even more
tweaks, but these are all minor things.  Performance gain by this
would be at most about 20%, I guess.    I'll let you know this later.



-sha





> But ExpressionFluxProcess isn't implemented completely yet.
> 
> I will report a brief introduction here when it is implemented
> comparatively.
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 

Hi, 

I have uploaded ExpressionFluxProcess on the CVS.

I verified ExpressionFluxProcess run time on Droslphila model 
and compared to Process run time.

Here is a comparison of usr times of FixdeODE1 runs:

            PythonFluxProcess    ExpressionFlux         Native(C++)
                                                       Process    
100s       19.715s                   0.971s                    0.527s
1000s     193.830s                 7.689s                    3.531s

ExpressionFluxProcess is about 2 times slower than Native(C++). 
But ExpressionFluxProcess is much faster than PythonFluxProcess. 
( about 25 times faster )

But ExpressionFluxProcess isn't implemented completely yet.

I will report a brief introduction here when it is implemented
comparatively.

The first one has been found to be a misunderstanding of the
specification.

The second bug has been fixed on the CVS, and it will be included
in the next release, which is scheduled around the end of this month.


-sha


> 804253 ecell core doesnt call Logger::log()  2003-09-11 17:57 
> 804256 cannot load Drosophila.eml  2003-09-11 18:00
> 
> 
> I couldn't reproduce the first one.  Still investigating.
> 
> The second one is caused by the error in loading PythonFluxProcess DM.
> 
> 
> We are preparing version 3.1.99 to fix these show stoppers.
> 
> 
> It seems like we need to have a better release quality control.
> At least doc/sample/* models should be checked before every release.
> 
> 
> -sha
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 

I would like to propose renaming gecell command (which currently
invokes osogo GUI) to ecell3-session-monitor.

It is just a better name because it is a GUI frontend of ecell3-session.
In fact it's official name is E-Cell Session Monitor.

But it is a bit longish.  Perhaps we can retain gecell command as an
alias to ecell3-session-monitor.


Any comments?

If there is no objection, I will do the renaming for the version 3.1.99.


-sha

I have placed boost 1.30.2 rpms taken from the latest rawhide
under 

http://ecell.sourceforge.net/additional-packages/


The next version 3.1.99 rpms should be built against this new version.


-sha

Gabor has found a couple of critical bugs in the current version 3.1.98.

804253 ecell core doesnt call Logger::log()  2003-09-11 17:57 
804256 cannot load Drosophila.eml  2003-09-11 18:00


I couldn't reproduce the first one.  Still investigating.

The second one is caused by the error in loading PythonFluxProcess DM.


We are preparing version 3.1.99 to fix these show stoppers.


It seems like we need to have a better release quality control.
At least doc/sample/* models should be checked before every release.


-sha

Dear Satya-san,

I rebuilt Python-2.2.2 with IBM's compiler vacpp.
This time, compiling Python-2.2.2 with gcc did not go well.
The newer version Python-2.3 did not go well with gcc, either.

With Python-2.2.2, I ran ecell3, but with IOT/Abort trap and core dumped.
Attached are the logs of the ecell session and gdb for analysing the core
dump.

Best regards,

Kazuhide Sugawara

------<ecell invocation>--------------------------
$ bash ecell3 /opt/freeware/bin/ecell3-session
ecell3-session [ E-Cell SE Version 3.1.95, on Python Version 2.2.2 ]
Copyright (C) 1996-2003 Keio University.
Send feedback to Kouichi Takahashi <sh...@e-...>
ecell3-session>>  loadModel('simple.eml')
IOT/Abort trap (core dumped)

------<analysing core dump with gdb>--------------------------
$ gdb python core
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-ibm-aix5.1.0.0"...
(no debugging symbols found)...
Core was generated by `python'.
Program terminated with signal 6, Aborted.
(no debugging symbols found)...(no debugging symbols found)...
#0  0xd005a9f0 in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)
(gdb) bt
#0  0xd005a9f0 in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)
#1  0xd005a000 in _p_raise () from /usr/lib/libpthreads.a(shr_xpg5.o)
#2  0xd01dcde0 in raise () from /usr/lib/libc.a(shr.o)
#3  0xd01eb89c in abort () from /usr/lib/libc.a(shr.o)
#4  0xd2c0d4a8 in __cxxabiv1::__terminate(void (*)()) (handler=@0x0: 0x1)
    at /home/sugawara/gcc-3.2.3/libstdc++-v3/libsupc++/eh_terminate.cc:47
#5  0xd2c0d530 in std::terminate() ()
    at /home/sugawara/gcc-3.2.3/libstdc++-v3/libsupc++/eh_terminate.cc:57
#6  0xd2c0d7fc in __cxa_throw (obj=0x0, tinfo=0xffffffff, dest=Cannot
access memory at address 0xffffffff)
    at /home/sugawara/gcc-3.2.3/libstdc++-v3/libsupc++/eh_throw.cc:77
#7  0xd3f5c8dc in StaticModuleMaker<libecs::Stepper, libecs::Stepper*
(*)()>::getAllocator(std::string const&) (this=0x2ff20b18,
classname=@0x20313d98)
    at /opt/freeware/include/c++/3.2.3/bits/stl_alloc.h:668
#8  0xd3f5c370 in SharedModuleMaker<libecs::Stepper, libecs::Stepper*
(*)()>::getAllocator(std::string const&) (this=0x2025d658,
classname=@0x2ff20e80)
    at ../../dmtool/ModuleMaker.hpp:296
#9  0xd3f5be2c in StaticModuleMaker<libecs::Stepper, libecs::Stepper*
(*)()>::make(std::string const&) (this=0x2025d658, classname=@0x2ff20e80)
    at ../../dmtool/ModuleMaker.hpp:221
#10 0xd3f4db28 in libecs::Model::createStepper(std::string const&,
std::string const&) (this=0x20271a78, aClassName=@0xffffffff,
anID=@0x2ff20e98)
    at Model.hpp:252
#11 0xd3ed5e84 in
libemc::LocalSimulatorImplementation::createStepper(std::string const&,
std::string const&) (this=0x0, aClassname=@0xffffffff,
    anId=@0xffffffff) at LocalSimulatorImplementation.hpp:166
utils.c:981: gdb-internal-error: virtual memory exhausted: can't allocate
16024 bytes.
An internal GDB error was detected.  This may make further
debugging unreliable.  Quit this debugging session? (y or n) n
Create a core file containing the current state of GDB? (y or n) n

Hi,

As some of you may have known, new version of E-Cell is out and
available at sourceforge.

E-Cell Simulation Environment Version 3.1.98 (Hekkway)


Highlights of this release are:

 - New addition of E-Cell SessionManager distributed computation 
   platform to the package. (sugi, ito, shafi)
 - New support for DAE (Differential-Algebraic equations). (kaizu)
 - Specialized Stepper for Generalized Mass Action equations. (kmaru)
 - A hybrid dynamic/static simulation method for metabolic pathways.  
   (tomo)


Version 3.1.97 was skipped and not publicly made available because the
development at that time was so heavy to tag the CVS.


Note that from this release boost needs to be built and installed
before the installation of ecell.   boost and other required rpms
for RH9 taken from RedHat rawhide are available here:
http://ecell.sourceforge.net/additional-packages/


We plan another release (3.1.99) within this month.


-sha
 
 
Changes from Version 3.1.97 (Hekkout)

      * added ESSYNSStepper, GMAProcess and sample model: branchG
        (kmaru).
      * added Session Manager implementation and sample (osugi)
      * added FluxDistributionProcess, FluxDistributionStepper and
        QuasiDynamicFluxProcess for Nakayama-hybrid
        algorithm (tkitayama)
      * added Nakayama-hybrid algorithm sample model: Toy_Hybrid
        (tkitayama)
      * bug fix: FixedRungeKutta4Stepper (tkitayama)
      * added a DAE sample model:Pendulum (kaizu)
      * added FixedDAE1Stepper (kaizu)
      * changed ESS suffix from .ess to .py (shafi)
      * renamed: MichaelisUniUniProcess -> MichaelisUniUniFluxProcess
        (shafi)
      * temporary update of ContinuousProcess (kaizu)
      * bug fix: eri2eml can process the /ENVIRONMENT system as a common
        system like others.(tsakurada)
      * added isContinuous() flag, some debugs, deprecated
        MichaelisUniUniReversibleProcess (shafi)
      * bug fix: RapidEquilibriumProcess (kaizu)
      * added the multi-line support (ad-hoc) which use a normalization
        of the end-of-line on xml. (tsakurada)
      * when giving a rng seed, add scheduler index to time() (shafi)
      * added Stepper::DiscreteProcessOffset (shafi)
      * added isContinuous() to Process.hpp (shafi)
      * renamed: PolymorphData -> PolymorphValue (shafi)
      * deleted getStepperPtr() from VariableProxy, and add theStateFlag
        to DifferentialStepper(kaizu)
      * fixed a bug in boost include dir specification (shafi,
        ecell3/ecell/configure.in)
 
 
Changes from Version 3.1.96 (Hekkorina)
 
      * added support for windows dll. a shared library (satyanandave)
      * update for gcc-3.3.1 in mingw (satyanandave)
      * removed some files from Loki library (shafi)
      * Variable::MolarConc and NumberConc can be set and loaded. 
        Removed Variable::Concentration (shafi)
      * renamed: R_N_A -> N_A_R (shafi)
      * added --with-boost-include-dir and --with-boost-lib-dir
        configure options (shafi)
      * moved DifferentialStepper destructor from .hpp to .cpp (shafi)
      * moved AdaptiveDifferentialStepper destructor from .hpp to .cpp
        (shafi)
      * support for pre-built boost (shafi)
      * renamed ecell3 command to ecell3-python (shafi)
      * added support for native windows compilation using MinGW
        (satyanandave)
      * added support to the VVector for MinGW to define type of ssize_t
        (satyanandave)
      * disable dlopen checking for cygwin, mingw and native windows
        (satyanandave)
      * bug fix:essfile load (tkitayama)
      * fixed 2 bugs: added a "make large" icon to TracerWindow plotarea
        also added category labels to TracerWindow (bgabor)
      * implemented feature requests (bgabor)
        * 734556 show the number of entities in EntityListWindow *
        2003-05-08 03:53 bgabor  shafi
        * 734558 Tune PropertyWindow.update() * 2003-05-08 03:55 bgabor
        shafi
        * 697807 Design of MainWindow * 2003-03-04 23:08 bgabor osugi
      * added support to the VVector for large files. (bgabor)
      * support for Debian compatibility added to the osogo (bgabor)

yes that is correct I agree with you.
see you soon,
Gabor
----- Original Message -----
From: "Kouichi Takahashi" <sh...@sf...>
To: <gab...@ta...>; <ece...@li...>
Cc: <sh...@sf...>
Sent: Friday, September 05, 2003 3:54 PM
Subject: [Ecell-devel] Re: more on logging


> gabor,
>
> Included ecell-devel.
>
>
> I'm trying to remember what we have discussed about this
> restructuring of the logger code in Tsuruoka this June.
>
> Please correct me if I'm wrong:
>
> - we have decided to get back to dp2 at the lowest level
>   (just use vvector of dp2)
>
> - we had somehow reached an agreement that the getData(s,e,i) that
>   can do interpolation is useful just for GUI that requires realtime
>   response to users.  --- getData(s,e,i) should be renamed to any other
>   better name, and users should use getData() or getData(s,e) without
>   interpolation for scientific purposes.
>
>
> As for the average calculation, (discrete (non-weighted) or continuous
> (weighted)), considering the main purposes (GUI plotting),
> weighted seems better to me.
>
>
> See you at Tsuruoka again soon,
> -sha
>
>
> > > Gabor,
> > >
> > >thank you for your idea.
> > >
> > >Please consider the following points:
> > >
> > >- sampling theorem. (see text books of Fourier analysis or digital
> > >  signal processing).   This tells that fixed interval sampling
> > >  at f Hz is sufficient to reproduce its power spectra and waveform
> > >  up to f/2 Hz.
> > >  Strictly this is only for fixed sampling, but at least we could
> > >  take it as a clue that the simple cropping (current impl.) is
> > >  not too bad.   Especially for discrete, stochastic simulation,
> > >  spectrum analysis is one of the most often used math.
> > >
> > >- simplicity.  As we discussed, the simple cropping is simple, and
> > >  more intuitive to users.  Usually most statistic data processing
> > >  methods assumes this, and for science users would be almost
> > >  exclusively using val.   When I proposed, avg, min, max were
> > >  mainly for GUI plotting.    Provided that users can set the
> > >  logging interval, I don't think they feel inconvenient with that.
> > >  I don't like the idea of separating discrete and continous
datapoints.
> > >  A variable is often shared by discrete and continuous Steppers.
> > >
> > >- storage/cpu.  Getting more storage is easier than having more CPU
> > >  power.  Now you can get a 2TB storage system for 20,000 USD.
> > >  200GB HDD is only about 200 USD or less.
> > >  The point of tuning we get most would be maximizing data logging
> > >  throughput.
> > >
> > >- use cases.   Yes, you are right.  ecell's eventual goal is large
scale
> > >  whole cell simulation.   We can't get enough storage for that even if
> > >  we have a 10TB RAID.   But wait, do we need to store all the data
from
> > >  the start of the simulation?     As far as I know, large scale
> > >  simulation people (such as nuke phys and astro phys) are sometimes
> > >  doing this way:  get the data each step (these simulations output
> > >  gigabytes of data at one step), process it, and discard the raw data,
> > >  then the next step.   For cell simulation stopping at each step is
> > >  stupid, but at least the cases from comp. physics  hints us a
> > >  possibility of data stream, rather than data storage.
> > >  For example, it may be possible for the logger to stream the raw data
> > >  into a pipe (or a sort of FIFO), and when the frontend reads the data
> > >  it releases the memory (or disk space).
> > >
> > >
> > >-sha
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>

gabor,

Included ecell-devel.


I'm trying to remember what we have discussed about this
restructuring of the logger code in Tsuruoka this June.

Please correct me if I'm wrong:

- we have decided to get back to dp2 at the lowest level
  (just use vvector of dp2)

- we had somehow reached an agreement that the getData(s,e,i) that
  can do interpolation is useful just for GUI that requires realtime
  response to users.  --- getData(s,e,i) should be renamed to any other
  better name, and users should use getData() or getData(s,e) without
  interpolation for scientific purposes.


As for the average calculation, (discrete (non-weighted) or continuous
(weighted)), considering the main purposes (GUI plotting), 
weighted seems better to me.


See you at Tsuruoka again soon,
-sha


> > Gabor,
> >
> >thank you for your idea.   
> >
> >Please consider the following points:
> >
> >- sampling theorem. (see text books of Fourier analysis or digital
> >  signal processing).   This tells that fixed interval sampling
> >  at f Hz is sufficient to reproduce its power spectra and waveform 
> >  up to f/2 Hz.
> >  Strictly this is only for fixed sampling, but at least we could
> >  take it as a clue that the simple cropping (current impl.) is
> >  not too bad.   Especially for discrete, stochastic simulation,
> >  spectrum analysis is one of the most often used math.   
> >
> >- simplicity.  As we discussed, the simple cropping is simple, and
> >  more intuitive to users.  Usually most statistic data processing
> >  methods assumes this, and for science users would be almost
> >  exclusively using val.   When I proposed, avg, min, max were
> >  mainly for GUI plotting.    Provided that users can set the 
> >  logging interval, I don't think they feel inconvenient with that.
> >  I don't like the idea of separating discrete and continous datapoints.
> >  A variable is often shared by discrete and continuous Steppers.
> >
> >- storage/cpu.  Getting more storage is easier than having more CPU
> >  power.  Now you can get a 2TB storage system for 20,000 USD.   
> >  200GB HDD is only about 200 USD or less.
> >  The point of tuning we get most would be maximizing data logging
> >  throughput.
> >
> >- use cases.   Yes, you are right.  ecell's eventual goal is large scale
> >  whole cell simulation.   We can't get enough storage for that even if
> >  we have a 10TB RAID.   But wait, do we need to store all the data from
> >  the start of the simulation?     As far as I know, large scale
> >  simulation people (such as nuke phys and astro phys) are sometimes
> >  doing this way:  get the data each step (these simulations output
> >  gigabytes of data at one step), process it, and discard the raw data,
> >  then the next step.   For cell simulation stopping at each step is
> >  stupid, but at least the cases from comp. physics  hints us a
> >  possibility of data stream, rather than data storage.
> >  For example, it may be possible for the logger to stream the raw data
> >  into a pipe (or a sort of FIFO), and when the frontend reads the data
> >  it releases the memory (or disk space).
> >
> >  
> >-sha