ecell-devel Mailing List for E-Cell System

> 1. find a vvector tmp file, for example, /var/tmp/vvector-0000-0000
>    (currently under /var/tmp, but will be changed to /tmp)
> 
> 2. f = open( '/var/tmp/vvector-0000-0000' )
> 
3. array = Numeric.fromstring( f.read() )

You have to specify a type here:

3. array = Numeric.fromstring( f.read(), Numeric.Float )

> 4. Numeric.reshape( array, ( 5, len(array) / 5 ) )


-- 

Gabor,

One more thing about TracerWindow.

Your code of rescaling works fairly well, but considering the speed of 
retrieving logger data from the core, I think we should even minimize the number
of rescaling.

Strategies I took in ecell1 were:
- Always use zero as a bottom line of the y-axis.
  This is not only economical, but also useful for users to get absolute scales of the
  values at a glance.    This may somewhat hinder to recognize small changes 
  of larger values, but instead I propose to enable plot updating in zooming mode.
  In this way, if a user want to make a close observation,  the zooming mode can be used.

- Use more clean numbers for scaling.   ecell1 chooses numbers with leading '5' or '1'.
  e.g.   1, 5, 10, 50, 100, 500...
  This is a sort of asymmetric scaling policy, but works well in practice.
  Originally I tried to use 10x scaling (1, 10, 100, 1000), but found it too coarse.
  So I adopted the 1 - 5 rule.


Hope this helps.

-sha

-- 

gabor,


I have found a way to directly read vvector files from python.

1. find a vvector tmp file, for example, /var/tmp/vvector-0000-0000
   (currently under /var/tmp, but will be changed to /tmp)

2. f = open( '/var/tmp/vvector-0000-0000' )

3. array = Numeric.fromstring( f.read() )

4. Numeric.reshape( array, ( 5, len(array) / 5 ) )



There are however some severe drawbacks:
- It's platform dependent.  No check for bit lengths and byte swapping.
- Not thread safe.  No file locking.

This will mainly help to speed up saving ECD files, though I don't know if this
is helpful for TracerWindow.

The new version of Numeric, numarray has fromfile() method which doesn't need to
create a string.   And there is even a support for mmapped files, which means that entire
copy of the data on memory is not needed.


Just a hint.


-sha

Version 3.1.6  (Hekkhouse)

Hopefully this is the last minor release before version 3.2.

3.2 is expected to come out in a week or so.



changes:

libecs))

- Property name change: Stepper::UserMax/MinInterval -> Max/MinInterval (kaizu)

- AdaptiveDifferentialStepper class (kaizu)

- DifferentialSteppers now changes time during recalculation steps (kaizu)

- A substantial amount of improvements/fixes in DormandPrince, Fehlberg, and other
  DifferentialSteppers (kaizu)

- Implemented interpolants for DormandPrince and Fehlberg (kaizu)

- inlined Variable::get/setFixed(), use isFixed() for usual purposes (sha)

- removed Stepper::ID and Entity::ID properties (sha)

- It now passes a current time to Stepper::integrate(), causing a change in timing
  of calling Stepper::setCurrentTime() to after Variable::integrate() (sha)

- Scheduler now checks for too small step intervals (sha)

- Minimum interval check for AdaptiveDifferentialStepper (kaizu)

-DormandPrince: calculate k1 at next step beforehand, but it isn't used now (kaizu)
 

libemc))

-  Throw an exception if logger, entity or stepper is tried to create when running (sha)
 

pyecell)

- Now using a modified version of TableIO module to load/save ECDDataFile (sha)


osogo))

-  merged Main and MessageWindows.  (gabor)

- Tracer layout change.  (gabor)

- .ini file parser implementation  (gabor)
 
- fix button of VariableWindow now works (sha)



-- 
Kouichi Takahashi <sh...@sf...>

Thank you for the patch, gabor.

It is now applied and uploaded to the CVS.

> In this patch I fixed the two message box related problems: hiding/unhiding
> or detaching/reattaching doesn't change dimensions of msgwindow.
> it also scrolls to the end of text when new strings are written into it.

Now it behaves nicely.  Thank you.

> I also implemented a simple code for utilizing .ini files to define
> parameters for osogo. for now only logger_min_interval parameter is used by
> the program, however it can be easily enhanced to hold other values as well,
> if needed.
> the ini files should bebuilt up to comply with ConfigParser class format.
> it's easy

It'd be nice if users can change the values from the preference menu,
eventually.


-sha

Hi,
In this patch I fixed the two message box related problems: hiding/unhiding
or detaching/reattaching doesn't change dimensions of msgwindow.
it also scrolls to the end of text when new strings are written into it.

I also implemented a simple code for utilizing .ini files to define
parameters for osogo. for now only logger_min_interval parameter is used by
the program, however it can be easily enhanced to hold other values as well,
if needed.
the ini files should bebuilt up to comply with ConfigParser class format.
it's easy
the file should be a text file with the folowing syntax

#this is a comment line
#first the section header (osogo) in square brackets
[osogo]
#followed by parameter : value
logger_min_interval : 1

this file should be placed into the same directory where the model (.eml and
.dm files) resides and osogo will read it when the .eml or .ess file is
loaded.

there is one osogo.ini file in the ~/osogo directory holding the default
values. this is read upon opening MainWindow.
Gabor

> have you thought about rewriting Logger code to return Python List instead
> of Numarray?

No, but just check /usr/include/python2.2/object.h, listobject.h and
floatobject.h.
It holds a PyObject struct for each item.  It's inefficient both in
space and time.  It is exactly the reason why array was invented.

The PyList isn't suitable for passing whole data.  Logger has a rawdata
which can be converted to array by a plain memcpy.

Converting to PyList in Tracer after getData() is still fine, because
the conversion is after getting small slices in the level of array.

-sha


> Tracerwindow is also converting Numarray to List.
> Gabor
> 
> ----- Original Message -----
> From: "Kouichi Takahashi" <sh...@sf...>
> To: <ece...@li...>
> Sent: Thursday, February 13, 2003 7:18 PM
> Subject: [Ecell-devel] ECD file i/o
> 
> 
> >
> > Performance of ECDDataFile i/o has been improved about 15x by using
> > TableIO C-module.  It was a bottleneck.
> >
> > My impression is it can be one more magnitude faster.
> > TableIO module is good, but it doesn't utilize numarray API, but
> > using standard PyList. (probably involves a data copy between array <->
> > list?)
> >
> > If we need even more efficiency, we'd be considering rewrite of TableIO.
> > Another option from which we can expect best speed is to use a binary
> > format by default, and provide a way to convert to/from text files.
> >
> > -sha
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> > are you planning your Web Server Security? Click here to get a FREE
> > Thawte SSL guide and find the answers to all your  SSL security issues.
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> > _______________________________________________
> > Ecell-devel mailing list
> > Ece...@li...
> > https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 
> 

Hi,
have you thought about rewriting Logger code to return Python List instead
of Numarray?
Tracerwindow is also converting Numarray to List.
Gabor

----- Original Message -----
From: "Kouichi Takahashi" <sh...@sf...>
To: <ece...@li...>
Sent: Thursday, February 13, 2003 7:18 PM
Subject: [Ecell-devel] ECD file i/o


>
> Performance of ECDDataFile i/o has been improved about 15x by using
> TableIO C-module.  It was a bottleneck.
>
> My impression is it can be one more magnitude faster.
> TableIO module is good, but it doesn't utilize numarray API, but
> using standard PyList. (probably involves a data copy between array <->
> list?)
>
> If we need even more efficiency, we'd be considering rewrite of TableIO.
> Another option from which we can expect best speed is to use a binary
> format by default, and provide a way to convert to/from text files.
>
> -sha
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel

Performance of ECDDataFile i/o has been improved about 15x by using
TableIO C-module.  It was a bottleneck.

My impression is it can be one more magnitude faster.
TableIO module is good, but it doesn't utilize numarray API, but
using standard PyList. (probably involves a data copy between array <->
list?)

If we need even more efficiency, we'd be considering rewrite of TableIO.
Another option from which we can expect best speed is to use a binary
format by default, and provide a way to convert to/from text files.

-sha

hi,

CVS in sourceforge is ready.

The new CVSROOT is:  

:ext:dev...@cv...:/cvsroot/ecell

for developers and

:pserver:ano...@cv...:/cvsroot/ecell

for anonymous users.

Visit here for more information:
http://sourceforge.net/cvs/?group_id=72485


-sha

hi,

ecell.sourceforge.net is now ready, although still waiting for cvsroot
to be imported.

Here is an suggestion about usage of that page, especially
the bug tracker and the task manager:


- Both of the bug tracker and the task manager has priority settings.
  It has 10-grades, 1 being the lowest and 10 is the highest.

  I'd like to suggest the following semantics of these grades:

   2 or smaller: effectiveness questionable 
   3:  may be included if someone insist
   4:  will be included when a patch is available
   5:  default -- may be included in the next release
   6:  should be included in the next major release
   7:  release criteria of the next major release
   8:  should be included in the next minor release
   9:  release criteria of the next minor release
   10: (reserved -- don't use)


The idea is simple:
You may check remaining tasks by sorting them by priority.
>=6 means it should be done before major release (3.2, 3.3, 3.4..), and
>=8 means it should be included in the next minor release (3.1.6, 3.2.0,...)

If <=3 it will not be included unless you dig up.

If you are not sure, leave it default.  Maintainer of the module will check
and change it if necessary.


-sha

Version 3.1.5 (Hekk-xon)


This release includes another critical bug fix of the simulator core
which causes *wrong simulation results* when step size is changing
frequently.

The packages are available on the old bioinformatics.org page.
We'll soon upload them to the new sourceforge site.


The next release 3.1.6 is expected around 21st this month.   Patches may
be sent via the patch manager interface or of the sourceforge.net or
email before 20th.   

If everything goes well 3.1.6 will become the last release in 3.1
series, but as far as I can see there are at least three factors that
can delay release of 3.2:

- New emtool (new .dm syntax)
- Simulator core interpolation mechanism of VariableProxy class
- LoggerWindow isn't working correctly

All of these are high priority tasks.


Changes:

libecs))

- Process class name changes: 
   theFirstZeroVariableReferenceIterator ->  theZeroVariableReferenceIterator
   theFirstPositiveVariableReferenceIterator ->  thePositiveVariableReferenceIterator
  (sha)

- Process class new methods:
   Int getZeroVariableReferenceOffset()
   Int getPositiveVariableReferenceOffset()
   (sha)

- cache size of VVector was changed from 40 to 1024 (sha)

- fixed wrong timing of updating Stepper::currenttime in Model::step()
(sha)

- logger bugfixes (gabor)

pyecell))

- empy was updated to the latest version 2.2.6 (sha)

osogo))

- TracerWindow improvements (gabor)

- Restored LoggerWindow (sha)


others))

- users manual: included empy manual as an appendix (sha)



-sha

Hi ecell-devel subscribers,

You are getting this email because you were subscribers of
ece...@bi... mailing list.

As we announced on the old ML, we have moved to sourceforge.

New address of the ML is:
ece...@li...
(Be careful: it is not ecell3-devel, but ecell-devel)

Do not post to the old ecell3-devel ML.  You won't get a response.


The new homepage of ecell development project is:
http://ecell.sourceforge.net/

and the new project summary page is here:
http://sourceforge.net/projects/ecell


If you were a registered developer, create an account on sourceforge.net
and let me know your id.  I'll add you as a developer on the new page.


Almost everything is ready now, but currently we are waiting for a
sourceforge admin to import our cvs tree.   For now, please refrain from
commiting to the cvs.



-sha