ecell-devel Mailing List for E-Cell System

Version 3.1.95 (Hekkyusan)  is available.


libecs))

 - VVector: a minor fix for OSX (sha)
 - New functor class DynamicCaster<> (sha)
 - Stepper: splited Stepper.[ch]pp to multiple files (sha)
 - Scheduler: minor bugfix (sha)

dmtool))

 - Dynamic loading bugfix in libltdl (sha)

EM/EML))

 - deleteEntityProperty() bugfix (taka-ken)
 -  speed enhancements in EMLLIB (sha)
 - ecell3-em2eml and eml2em: added check for file extensions (taka-ken)
 
Standard DM Library))

 - NRProcess, NRStepper: (critical) bugfixes, refactoring, added declareUnidirectional() (sha)
 - NRProcess: the unit of k for second order reactions is now 1/(s M), not 1/(s (#/L)). (sha)
 - CatalyzedMassAction: bugfix (sha)
 - ODE45Stepper: minor improvements (sha)
 - SSystemProcess: minor improvements (kmaru)
 
Osogo))

 - BargraphWindow, TracerWindow and PropertyWindow improvements (gabor)
 - refactored MainWindow (sugi)
 - added BoardWindow (sugi)
 - PropertyWindow on EntityListWindow updates immediately (sugi)
 - bugfix about 'fix' checkbox of VariableWindow (sugi)
 - Only one FileSelection displayed at same time (sugi)
 - Do not display expected error message on MessageWindow (sugi)
 - Multiple loggers can be created at once (sugi)
 - New icons (sugi, tomo)
 - StepperWindow keeps selection, and update properties immediately (sugi)
 

Build mechanism)) 

 - added doc-install  (sakurada)

 
-sha

Hi Joerg,=20


Thank you for your contribution to ecell.

We will make a new release (probably version 1.1.2) to include your fixes.

ecell3 will become the 'current' branch shortly, and it includes the code=
 from
the 'standard reactors'.  Your patch will also be applied to the new vers=
ion.

I think you are also working on SBML support.   Could you post any
impression or result of your work to ecell-devel so that we can continue
our collaboration?


regards,
-sha


> I found a few errors in ecell-1 and ecell-2, and I would like to share=20
> the patches for these.
>=20
> The patches change the following:
>=20
> 1. Improved formatting of output (file: Tracer.C)
>=20
> 2. Added formatting of reactor description to latex to makefile, make 	=
=09
>      tex is now possible.
>      (file: standard-reactors/Makefile)
>=20
> 3. Corrected documentation and calculation in two standard reactors
>      (OrderedUniBiReactor.rd  and OrderedBiUniReactor.rd)
>      The error was a confusion between KcF and KcR in the last term
>      of the denominator.
>=20
> 4. Corrected the test for flux below zero in FluxReactor.h.
>     This test was in error for substrates/products with coefficent > 1 =
in
>     the function process().
>     (file: Fluxreactor.h).
>=20
> These errors also affect derived files, such as those where users have=20
> modified FluxReactor.h. The errors also affect ecell-2.
>=20
> The patch file is attached.
>=20
> I will leave Tsuruoka next week and return to Germany. Thank you to=20
> those who shared information with me during my stay at Fujisawa and=20
> Tsuruoka.
>=20
> Best regards, J=F6rg Weimar.

Dear E-cell users,

I found a few errors in ecell-1 and ecell-2, and I would like to share=20
the patches for these.

The patches change the following:

1. Improved formatting of output (file: Tracer.C)

2. Added formatting of reactor description to latex to makefile, make 	=09
     tex is now possible.
     (file: standard-reactors/Makefile)

3. Corrected documentation and calculation in two standard reactors
     (OrderedUniBiReactor.rd  and OrderedBiUniReactor.rd)
     The error was a confusion between KcF and KcR in the last term
     of the denominator.

4. Corrected the test for flux below zero in FluxReactor.h.
    This test was in error for substrates/products with coefficent > 1 in=

    the function process().
    (file: Fluxreactor.h).

These errors also affect derived files, such as those where users have=20
modified FluxReactor.h. The errors also affect ecell-2.

The patch file is attached.

I will leave Tsuruoka next week and return to Germany. Thank you to=20
those who shared information with me during my stay at Fujisawa and=20
Tsuruoka.

Best regards, J=F6rg Weimar.

--=20
PD Dr. Joerg R. Weimar, Inst. f. Wissensch. Rechnen, TU-Braunschweig
J.W...@tu..., http://www.tu-bs.de/institute/WiR/weimar
Tel. +49-531-391-3006  Mail: D-38092 Braunschweig

hi,

I've even refactored NRStepper and NRProcess classes (for
Gillespie-Gibson algorithm, or the Next Reaction method).

Now NRProcess doesn't assume to be used in conjunction with NRStepper.

NRProcess is now more generic, and could be used for any variations of the
Gillespie's algorithm (including the original First Reaction method and the TauLeap method.).

The design is very clear:  NRProcess calculates propensity, checks for 
dependencies between Processes if necessary, and changes
values of variables.   NRStepper just schedules the Processes according to the Gibson's
algorithm.

I'm going to rename it as GillespieProcess before the release of version 3.2.


regards,
sha

just to note...

The libltdl distributed with ecell3 has been modified to fix a bug, and now differs from
that from libtool 1.4.3.

The bug prevented DM loading to work correctly.  (It looks for .la, but won't do so for .so)
A patch from the current CVS HEAD of libtool was backported:

http://savannah.gnu.org/cgi-bin/viewcvs/libtool/libtool/libltdl/ltdl.c.diff?r1=1.170&r2=1.171&diff_format=h

This patch is not yet included in libtool releases (as of 1.4.3).

A workaround for this bug has been removed from dmtool/DynamicModule.hpp.


Another thing related is the porting to Darwin.   

So far we have succeeded to compile libecs on a OSX box, but 
at least officially libtool doesn't support that platform until recently
(Mar. 20, 2003).   

http://savannah.gnu.org/cgi-bin/viewcvs/libtool/libtool/libltdl/ltdl.c.diff?r1=1.172&r2=1.173&diff_format=h


We need to maintain our copy of libltdl until the next release of libtool comes up,
and at least it is included in the latest version of RedHat.


-sha

> Now ecell3-em2eml is pretty good.
> 
> 
> When I ran Automata model in ecell3, I think most big problem 
> that running big model like Automata is loadModel() part.
> Now em2eml part is far faster than it was.
> 
> I donot know (2)schema works better for loadModel() part.

In loadModel() most time is consumed by minidom.parse().
Time of XML parsing is assumed to be proportional to the number of XML tags.
Reducing the number of <value> tags just means better performance in this case.

-sha


> tomo
> 
> Kouichi Takahashi <sh...@sf...> wrote:
> 
> > hi,
> > 
> > I've worked on something to improve em/eml processing speed.
> > (emparse.py and eml.py)
> > 
> > Currently it takes too much time (>10min) to run ecell3-em2eml to parse a cellular automata
> > .em file (~8MB).
> > 
> > Now ecell3-em2eml and Session.loadModel() runs slightly faster (~30% improvement).
> > 
> > There are two points I've noticed:
> > 
> > (1)  Profiling shows that emparse.py and eml.py is now fairly well written, and most
> >       time is consumed inside Python's XML processing library, especially in 
> >       minidom and pyexpat.
> > 
> >       One possibility might be to use a faster XML processor.
> > 
> > 
> > (2) I also found that the biggest bottleneck in case of the CA model is to parse/create 
> >      <value> elements in EML.
> > 
> >      If a property value of a certain entity is a nested list like this,
> > 
> > [ 0 [ A B ] 1 1 1 ... 3 3 3 ]
> > 
> >     currently the <value> elements are also nested like this in EML:
> > 
> > <value>
> > <value>
> > 0
> > </value>
> > <value>
> > A
> > </value>
> > <value>
> > B
> > </value>
> > ...
> > 
> > 
> >     At least currently, there is no need to parse so deeply like this. 
> >     
> >     Thus another possibility is not to parse the property values at all, but only do some
> >     syntax checking and standardization.   
> > 
> >     For example, a property value like this
> > 
> > [ 0 
> >     [ A B ] 1 
> >       "string"       1 ]
> > 
> >     would be standardized like this.
> > 
> > <value>[ 0 [ A B ] 1 "string" 1 ]</value>
> > 
> > 
> > 
> > Comments needed.
> > -sha
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ValueWeb: 
> > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> > No other company gives more support or power for your dedicated server
> > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> > _______________________________________________
> > Ecell-devel mailing list
> > Ece...@li...
> > https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 
> 

Thank you shafi-san.

Now ecell3-em2eml is pretty good.


When I ran Automata model in ecell3, I think most big problem 
that running big model like Automata is loadModel() part.
Now em2eml part is far faster than it was.

I donot know (2)schema works better for loadModel() part.

Does (2)schema work good for cutting short loadModel() time?

tomo

Kouichi Takahashi <sh...@sf...> wrote:

> hi,
> 
> I've worked on something to improve em/eml processing speed.
> (emparse.py and eml.py)
> 
> Currently it takes too much time (>10min) to run ecell3-em2eml to parse a cellular automata
> .em file (~8MB).
> 
> Now ecell3-em2eml and Session.loadModel() runs slightly faster (~30% improvement).
> 
> There are two points I've noticed:
> 
> (1)  Profiling shows that emparse.py and eml.py is now fairly well written, and most
>       time is consumed inside Python's XML processing library, especially in 
>       minidom and pyexpat.
> 
>       One possibility might be to use a faster XML processor.
> 
> 
> (2) I also found that the biggest bottleneck in case of the CA model is to parse/create 
>      <value> elements in EML.
> 
>      If a property value of a certain entity is a nested list like this,
> 
> [ 0 [ A B ] 1 1 1 ... 3 3 3 ]
> 
>     currently the <value> elements are also nested like this in EML:
> 
> <value>
> <value>
> 0
> </value>
> <value>
> A
> </value>
> <value>
> B
> </value>
> ...
> 
> 
>     At least currently, there is no need to parse so deeply like this. 
>     
>     Thus another possibility is not to parse the property values at all, but only do some
>     syntax checking and standardization.   
> 
>     For example, a property value like this
> 
> [ 0 
>     [ A B ] 1 
>       "string"       1 ]
> 
>     would be standardized like this.
> 
> <value>[ 0 [ A B ] 1 "string" 1 ]</value>
> 
> 
> 
> Comments needed.
> -sha
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel

hi,

I've worked on something to improve em/eml processing speed.
(emparse.py and eml.py)

Currently it takes too much time (>10min) to run ecell3-em2eml to parse a cellular automata
.em file (~8MB).

Now ecell3-em2eml and Session.loadModel() runs slightly faster (~30% improvement).

There are two points I've noticed:

(1)  Profiling shows that emparse.py and eml.py is now fairly well written, and most
      time is consumed inside Python's XML processing library, especially in 
      minidom and pyexpat.

      One possibility might be to use a faster XML processor.


(2) I also found that the biggest bottleneck in case of the CA model is to parse/create 
     <value> elements in EML.

     If a property value of a certain entity is a nested list like this,

[ 0 [ A B ] 1 1 1 ... 3 3 3 ]

    currently the <value> elements are also nested like this in EML:

<value>
<value>
0
</value>
<value>
A
</value>
<value>
B
</value>
...


    At least currently, there is no need to parse so deeply like this. 
    
    Thus another possibility is not to parse the property values at all, but only do some
    syntax checking and standardization.   

    For example, a property value like this

[ 0 
    [ A B ] 1 
      "string"       1 ]

    would be standardized like this.

<value>[ 0 [ A B ] 1 "string" 1 ]</value>



Comments needed.
-sha

Christian,

I'm glad to know it's working for you now.

I've tested with gcc-3.2.2 (on RH9), and it works fine.   I thought it is caused
by some patch on GCC CVS (3.2.3-pre) introduced after the release of 3.2.2.
Are you still using 3.2.3?


> On Wed, Apr 02, 2003 at 05:02:38PM +0900, Kouichi Takahashi wrote:
> > So what's the problem?
> dunno. but now it works. i cant remember that i did something special - i 
> would say there was something wrong with my installation and/or the 
> compiler. everything i did was to change here something, do this and that,
> try this, move this here, reinstall that and so on - you know what i mean :)
> 
> is there any documentation of the basics of e-cell? how the core is
> organized, how it works and stuff like that?

I think if you have already browsed ecell.sourceforge.net, you may have read those materials.
If not yet,  there is an incomplete users-manual here.    
I'm going to complete this within a few months.  (Before my Ph.D. thesis.. possibly..) 

http://ecell.sourceforge.net/documentation.html

and an article ''E-Cell 3: Object-based Software Environment for Cell Modeling and Simulation''
which briefly describes its architecture is here:

http://ecell.sourceforge.net/readings.html


-sha

On Wed, Apr 02, 2003 at 05:02:38PM +0900, Kouichi Takahashi wrote:
> So what's the problem?
dunno. but now it works. i cant remember that i did something special - i=
=20
would say there was something wrong with my installation and/or the=20
compiler. everything i did was to change here something, do this and that,
try this, move this here, reinstall that and so on - you know what i mean :)

is there any documentation of the basics of e-cell? how the core is
organized, how it works and stuff like that?

christian
--=20
pgp: 0x785D1612 (try http with pgp.mit.edu on port 80)

Thanks shafi-san.

I try compile again, and report install-status.

Kouichi Takahashi <sh...@sf...> wrote:

> tomo,
> 
> 
> > I test ecell3 compile in mac osx platform and I could not 
> > install.I found some problems.
> 
> OSX is an important target platform, as it is very common among biologists.
>     
> 
> > 1,compile filed
> > After I installed gsl and numpy and boost_1_29_0,I test ecell3 
> > compile.this error occured in libecs/VVector.cpp.
> 
> 
> > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../.. -I/Users/skipper/boost 
> > -I/Users/skipper/ecell-3.1.93 -I../../libltdl -g -O2 -c VVector.cpp -MT 
> > VVector.lo -MD -MP -MF .deps/VVector.TPlo  -fno-common -DPIC -o 
> > VVector.lo
> > VVector.cpp:267: prototype for `void vvectorbase::my_open_to_read(long 
> > long
> >     int)' does not match any in class `vvectorbase'
> > VVector.h:124: candidate is: void vvectorbase::my_open_to_read(long int)
> > make[1]: *** [VVector.lo] Error 1
> > make: *** [all-recursive] Error 1
> 
> 
> Seems there is a type mismatch.
> 
> The prototype is
> 
> vvectorbase::my_open_to_read( long )
> 
> while the call is passing off_t, which seems to be long long in OSX.
> Probably off_t is long on Linux.
> 
> I have modified VVector.h like this:
> 
> vvectorbase::my_open_to_read( off_t )
> 
> 
> Please try it again with the latest CVS snapshot.
> 
> 
> -sha
> 
> -- 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel

tomo,


> I test ecell3 compile in mac osx platform and I could not 
> install.I found some problems.

OSX is an important target platform, as it is very common among biologists.
    

> 1,compile filed
> After I installed gsl and numpy and boost_1_29_0,I test ecell3 
> compile.this error occured in libecs/VVector.cpp.


> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../.. -I/Users/skipper/boost 
> -I/Users/skipper/ecell-3.1.93 -I../../libltdl -g -O2 -c VVector.cpp -MT 
> VVector.lo -MD -MP -MF .deps/VVector.TPlo  -fno-common -DPIC -o 
> VVector.lo
> VVector.cpp:267: prototype for `void vvectorbase::my_open_to_read(long 
> long
>     int)' does not match any in class `vvectorbase'
> VVector.h:124: candidate is: void vvectorbase::my_open_to_read(long int)
> make[1]: *** [VVector.lo] Error 1
> make: *** [all-recursive] Error 1


Seems there is a type mismatch.

The prototype is

vvectorbase::my_open_to_read( long )

while the call is passing off_t, which seems to be long long in OSX.
Probably off_t is long on Linux.

I have modified VVector.h like this:

vvectorbase::my_open_to_read( off_t )


Please try it again with the latest CVS snapshot.


-sha

-- 

Version 3.1.93 (Hekril)


This is the fourth pre-3.2 release.


I'll sort out the bug/feature trackers, but 
currently we have three bugs with 6+ priority, and seven 5+ priority
bugs.

At least these bugs must be fixed before 3.2.


If you have an already fixed problem which isn't updated on the
trackers, or a bug which isn't put into the trackers yet, please make it now.



-sha


Changes:

standard dm library))

- NRStepper/NRProcess: a critical bugfix.  (caused wrong simulations) (sha)

pyecell))

- 'info' field support in .em files (taka-ken)

- a minor bugfix in Session.saveModel() (taka-ken)


osogo))

- a scaling bugfix of the TracerWindow (gabor)


others))
- create documents and install at the "make install" (tsakurada)



-- 

Hi ecell3-devel member.

I test ecell3 compile in mac osx platform and I could not 
install.I found some problems.

1,compile filed

After I installed gsl and numpy and boost_1_29_0,I test ecell3 
compile.this error occured in libecs/VVector.cpp.

Making all in dmtemplates
Making all in Process
make[2]: Nothing to be done for `all'.
make[2]: Nothing to be done for `all-am'.
source='VVector.cpp' object='VVector.lo' libtool=yes \
depfile='.deps/VVector.Plo' tmpdepfile='.deps/VVector.TPlo' \
depmode=gcc3 /bin/sh ../../depcomp \
/bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. 
  -I../.. -I/Users/skipper/boost -I/Users/skipper/ecell-3.1.93 
-I../../libltdl    -g -O2  -c -o VVector.lo `test -f 'VVector.cpp' || 
echo './'`VVector.cpp
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../.. -I/Users/skipper/boost 
-I/Users/skipper/ecell-3.1.93 -I../../libltdl -g -O2 -c VVector.cpp -MT 
VVector.lo -MD -MP -MF .deps/VVector.TPlo  -fno-common -DPIC -o 
VVector.lo
VVector.cpp:267: prototype for `void vvectorbase::my_open_to_read(long 
long
    int)' does not match any in class `vvectorbase'
VVector.h:124: candidate is: void vvectorbase::my_open_to_read(long int)
make[1]: *** [VVector.lo] Error 1
make: *** [all-recursive] Error 1

Mac osx is based on BSD.Now ecell3 is developed in Linux.
there are some differences from BSD VVector to Linux header, 
maybe.I want help for install ecell3 in mac osx.

2.Osogo does not run.
Now mac osx has X Window System and gtk,but mac osx gtk is 
gtk1.3 base.Osogo can not run in mac osx.

Hi Christian,

added ecell-devel.


Perhaps I was wrong.   I've tested it with boost-1.30.0, and found no
problem.

So what's the problem?
Is gcc-3.2.3 not compatible with gcc-3.2.1?
I'll test this then.


-sha




> i just tried to compile ecell 3.1.93 and got the following compiler error:
> 
> # sudo make
> [...]
> /home/christian/boost/boost/cast.hpp:178: warning: decimal constant is
> so large that it is unsigned (this warning doesn't seem to be related
> to the error, but maybe it helps you)
> [...]
> /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -I/home/christian/boost -I.. -I/home/christian/ecell-3.1.93 -I../../libltdl -I/usr/include/python2.2 -ftemplate-depth-70 -c -o registry.lo `test -f 'registry.cpp' || echo './'`registry.cpp
> g++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -I/home/christian/boost -I.. -I/home/christian/ecell-3.1.93 -I../../libltdl -I/usr/include/python2.2 -ftemplate-depth-70 -c registry.cpp -MT registry.lo -MD -MP -MF .deps/registry.TPlo  -fPIC -DPIC -o registry.lo
> registry.cpp: In function `void 
>    boost::python::converter::registry::insert(PyObject*(*)(const void*), 
>    boost::python::type_info)':
> registry.cpp:72: no matches converting function `to_python' to type `struct 
>    PyObject*(*)(const void*)'
> /home/christian/boost/boost/python/converter/registrations.hpp:40: candidates 
>    are: PyObject* boost::python::converter::registration::to_python(const 
>    volatile void*) const
> make[4]: *** [registry.lo] Error 1
> make[4]: Leaving directory `/home/christian/ecell-3.1.93/ecell/pyecs'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/home/christian/ecell-3.1.93/ecell'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/christian/ecell-3.1.93/ecell'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/christian/ecell-3.1.93'
> make: *** [all] Error 2
> 
> (see http://www.kieft.de/ecell-compiler-error)
> 
> I've looked at registry.cpp but couldn't figure what the error acually
> is.
> 
> compiler:
> # g++ -v
> Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.3/specs
> Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc i386-linux
> Thread model: posix
> gcc version 3.2.3 20030210 (Debian prerelease)
> 
> 
> Regards,
> Christian Kieft
-- 

Hi,
Of course, I would be happy to do this as like databases very much.
but I don't know if my profile and availability could fit this task.
Gabor
----- Original Message -----
From: "Kouichi Takahashi" <sh...@sf...>
To: <ece...@li...>
Cc: <sh...@sf...>
Sent: Tuesday, April 01, 2003 10:52 AM
Subject: [Ecell-devel] Osogo: support for the largest database


> Hi ecell-devel people,
>
> I have been discussing with scientists here in E-Cell Project, Keio Univ.
and other
> colleagues from many countries including UK, Germany, US, and Singapore,
about the
> support for more large-scale, and sophisticated database support in E-Cell
3's primary
> GUI component, Osogo Session Manager.
>
> As we have argued in the previous work,
>
> "Computational challenges in cell simulation" Takahashi, K., Yugi, K.,
Hashimoto, K.,
> Yamada, Y., Pickett, C., and Tomita, M.: IEEE Intelligent Systems 17:5,
64-71, 2002
>
> knowledge and data processing in cell modeling and simulation is one of
the most
> important and challenging computational challenges.
>
> There are many public databases available on the net, such as BRENDA,
EcoCyc, and
> PubMed.    But in the process of surveying such databases we have found
that
> there is one which comprehensively covers virtually all the knowledge and
documents
> freely available on the net.   Fortunately the database provides public
APIs for many
> languages including Perl, Java, PHP, .NET, and of course, Python.
>
> http://www.zdnet.com/anchordesk/stories/story/0,10738,2913142,00.html
>
>
> I believe this new feature promises E-Cell users a more transparent access
to
> biological, computational and any other knowledge resources even while the
> simulation is running.    In 80's a famous joke in hacker's community was
that
> every non-trivial applications dilates to get an email support.   Now who
denies the
> benefit of having 'Google search' button on the Osogo's control panel?
> A volunteer wanted.
>
>
> -sha
>
>
> --
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel

Hi ecell-devel people,

I have been discussing with scientists here in E-Cell Project, Keio Univ. and other
colleagues from many countries including UK, Germany, US, and Singapore, about the
support for more large-scale, and sophisticated database support in E-Cell 3's primary
GUI component, Osogo Session Manager.

As we have argued in the previous work,

"Computational challenges in cell simulation" Takahashi, K., Yugi, K., Hashimoto, K., 
Yamada, Y., Pickett, C., and Tomita, M.: IEEE Intelligent Systems 17:5, 64-71, 2002

knowledge and data processing in cell modeling and simulation is one of the most 
important and challenging computational challenges.

There are many public databases available on the net, such as BRENDA, EcoCyc, and
PubMed.    But in the process of surveying such databases we have found that
there is one which comprehensively covers virtually all the knowledge and documents
freely available on the net.   Fortunately the database provides public APIs for many
languages including Perl, Java, PHP, .NET, and of course, Python.

http://www.zdnet.com/anchordesk/stories/story/0,10738,2913142,00.html


I believe this new feature promises E-Cell users a more transparent access to
biological, computational and any other knowledge resources even while the
simulation is running.    In 80's a famous joke in hacker's community was that
every non-trivial applications dilates to get an email support.   Now who denies the
benefit of having 'Google search' button on the Osogo's control panel?
A volunteer wanted.


-sha


--