ecell-devel Mailing List for E-Cell System

Koizumi-san,

Software architecture is a grand art.  I'm in this business
for more than twelve years, and I still learn something everyday.

I've got an impression that you are qualified and are able to
think deeply about things.  You are a valuable member of the
E-Cell development team.

I think my previous messages included background info and rationale
that should be sufficient for you to think more deeply about E-Cell's
higher level architecture.  I would appreciate if you could read
carefully the messages yet again.  I'm happy to answer more
questions and clarify things if you still have any doubts after
a week.

-sha





> 2007/3/23, Koichi Takahashi <sh...@sf...>:
>> - Languages;   We need to keep in mind why we want to mix
>>    languages in the first place.  There is one and only one
>>    reason, that is, compiled languages that are fast enough for
>>    doing high performance numerical simulation are almost always
>>    too technical, complicated, overkill and thus less productive
>>    for frontend programming and user scripting.  When you talk
>>    about this you need to always remember there is
>>    absolutely no other reasons.
>>
>>    For this very reason, the combination must be a statically
>>    typed, natively compiled system language and a dynamic
>>    scripting language.  For this very reason, the combination
>>    used in E-Cell 2, C++/Java via C/JNI was nothing but
>>    ridiculous.  For this reason, none of C++/C#, Java/Ruby nor
>>    C#/Perl make sense for our particular case.  But C++/Python does.
> 
> Agreed. Probably you got me a bit wrong; I didn't say the Java and C++
> mixture would make sense that way. What I said is about virtual
> machines that backed the languages. Is there something not fully
> explained?
> 
>>    Our system language must be C++ because it must
>>    be transparently compatible to C to utilize tons of high quality
>>    numerical computation code written in the past twenty years
>>    available out there, and must support object orientation to
>>    cope with the complexity of E-Cell object model.  Competitors
>>    in this area may include Objective-C and D, but
>>    the former doesn't run as fast as C++, and D is still premature.
> 
> Such performance comparison doesn't seem meaningful since that totally
> depends on the context they are used. I can't tell if Objective-C is
> generally slower than C++ using smart pointers because they use the
> same strategy for memory management indeed. Anyways, C++ gets its
> place, and so do others. If a mere interface issue that is easily
> resolvable keeps all them from being used as backend languages, why
> not allow them to go?
> 
>>    Our frontend language is not Ruby because it is not comparable in
>>    terms of the scale of user community both in general and scientific
>>    computing, and thus yet to achieve the critical mass that makes us
>>    safe to rely on it and furthermore, lacks a number of third party
>>    modules important for us.   I cannot say I would expect for sure
>>    that the Ruby/Perl/C# scientific computing communities will be still
>>    actively alive in 2017, but Python's surely will be.
> 
> What makes the choice varies by the user which might not be reduced
> into the single word 'us"; if one simply buys into Python, she will
> use it. I just hope there will be some options if possible. And if we
> can make it flexible, then it'd be better off doing so.
> 
>>    What I'm sad about is simply that the E-Cell IDE project is repeating
>>    the mistake E-Cell 2 made.  Not only that its fundamental technical
>>    architecture is wrong, but also is it developing a wrong set of
>>    features to wrong hypothetical users that are nonexistent.
> 
> Well, that might be the point that I'd like to hear from you in the
> first place. So the question is why you have been watching the project
> to go towards a wrong direction so far while you are also interested
> in GUI frontends? Would there be anything we could do better?
> 
>>    Two, if so, E-Cell IDE's users must not be limited to what you call
>>    'novices'.  However, then, the contradiction is E-Cell IDE built
>>    within the .NET environment cannot become or replace E-Cell's
>>    main modeling environment because it's not portable to
>>    at least two of our most important target platforms (OSX and
>>    linux).  (Don't mention Mono here, it's for running something
>>    that was already built in C#, and not for making new cross
>>    platform stuff)
> 
> That's not what Mono's for. CLR is platform-independent in nature and
> the Mono team implemented it in portable way. That's it. No need to
> mention Mono is not about a mere Microsoft copy, but a runtime
> environment on which many static / dynamic types of languages can run.
> 
>> It seems to me the only reason made up to justify
>>    such use of .NET was to provide a slightly better look&feel and
>>    better integrations to other parts of MS Windows environment to
>>    attract 'new users'.  You need to realize how tiny such a thing
>>    is considering the drawbacks of (1) duplicated codes/efforts that
>>    will be abandoned as soon as we switch to ecell4, (2) a danger of
>>    branching of the code and the development organization, (3) a
>>    significantly less efficient use of human/institutional/financial
>>    resources given to the ecell project.  (4) confusing users.
> 
> These are somewhat pointless; the mentioned side-effects are not
> caused by the architecture, but the arrangement of the project.
> Therefore I don't think being stick to Python / C++ / GTK would have
> resulted in a better situation.
> 
>>    What we should have learned from the failure of the E-Cell 2 project
>>    was how unthoughtful architectural decisions and political
>>    interferences can demolish sound development and success of
>>    software projects and how miserable it can be.
> 
> It looks like it was not you that made the decision about architecture
> and so you thought you could make it better. Could we really dismiss
> all the passage that simply?
> 
>>    What we need to do now is to think hard how this can be made
>>    more constructive.  A good portion of E-Cell development is
>>    being run thanks to fundings that come from Japanese government.
>>    It's about two years since I moved to California.
>>    One thing I think Japanese science may need to learn from
>>    America is how agile people here make appropriate maneuvers
>>    once they know they were running into a wrong direction.
>>    That's what we need to learn here.
> 
> Got to do stuff in a more constructive way -- where I fully agree. I
> think we should be more flexible at our thought, an pay attention to
> what each other is doing without dismissing it stereotypically. With
> regards to the latter issue I thought of a different reasoning about
> this, but I'd like to tell you this one elsewhere as it's going  to be
> off-topic.
> 
>> - C-Python vs CLR runtimes;  I couldn't get your point.
>>    There is no point in comparing such different
>>    architectures of Python VM and of C# VM.  C# should be compared
>>    to Java.  Python is in the same world as Ruby or Perl.
>>    Nevertheless, you understand any CLR languages are
>>    not our option because with them we are not able to achieve the
>>    level of portability we decided to need.
> 
> Although I'm not persist on CLR, I mentioned just for an example of a
> VM architecture in the first place,  what do you think makes the CLR
> less portable in this context?
> 
> Regards,
> Moriyoshi
> 

2007/3/23, Koichi Takahashi <sh...@sf...>:
>
> - Languages;   We need to keep in mind why we want to mix
>    languages in the first place.  There is one and only one
>    reason, that is, compiled languages that are fast enough for
>    doing high performance numerical simulation are almost always
>    too technical, complicated, overkill and thus less productive
>    for frontend programming and user scripting.  When you talk
>    about this you need to always remember there is
>    absolutely no other reasons.
>
>    For this very reason, the combination must be a statically
>    typed, natively compiled system language and a dynamic
>    scripting language.  For this very reason, the combination
>    used in E-Cell 2, C++/Java via C/JNI was nothing but
>    ridiculous.  For this reason, none of C++/C#, Java/Ruby nor
>    C#/Perl make sense for our particular case.  But C++/Python does.

Agreed. Probably you got me a bit wrong; I didn't say the Java and C++
mixture would make sense that way. What I said is about virtual
machines that backed the languages. Is there something not fully
explained?

>    Our system language must be C++ because it must
>    be transparently compatible to C to utilize tons of high quality
>    numerical computation code written in the past twenty years
>    available out there, and must support object orientation to
>    cope with the complexity of E-Cell object model.  Competitors
>    in this area may include Objective-C and D, but
>    the former doesn't run as fast as C++, and D is still premature.

Such performance comparison doesn't seem meaningful since that totally
depends on the context they are used. I can't tell if Objective-C is
generally slower than C++ using smart pointers because they use the
same strategy for memory management indeed. Anyways, C++ gets its
place, and so do others. If a mere interface issue that is easily
resolvable keeps all them from being used as backend languages, why
not allow them to go?

>    Our frontend language is not Ruby because it is not comparable in
>    terms of the scale of user community both in general and scientific
>    computing, and thus yet to achieve the critical mass that makes us
>    safe to rely on it and furthermore, lacks a number of third party
>    modules important for us.   I cannot say I would expect for sure
>    that the Ruby/Perl/C# scientific computing communities will be still
>    actively alive in 2017, but Python's surely will be.

What makes the choice varies by the user which might not be reduced
into the single word 'us"; if one simply buys into Python, she will
use it. I just hope there will be some options if possible. And if we
can make it flexible, then it'd be better off doing so.

>    What I'm sad about is simply that the E-Cell IDE project is repeating
>    the mistake E-Cell 2 made.  Not only that its fundamental technical
>    architecture is wrong, but also is it developing a wrong set of
>    features to wrong hypothetical users that are nonexistent.

Well, that might be the point that I'd like to hear from you in the
first place. So the question is why you have been watching the project
to go towards a wrong direction so far while you are also interested
in GUI frontends? Would there be anything we could do better?

>    Two, if so, E-Cell IDE's users must not be limited to what you call
>    'novices'.  However, then, the contradiction is E-Cell IDE built
>    within the .NET environment cannot become or replace E-Cell's
>    main modeling environment because it's not portable to
>    at least two of our most important target platforms (OSX and
>    linux).  (Don't mention Mono here, it's for running something
>    that was already built in C#, and not for making new cross
>    platform stuff)

That's not what Mono's for. CLR is platform-independent in nature and
the Mono team implemented it in portable way. That's it. No need to
mention Mono is not about a mere Microsoft copy, but a runtime
environment on which many static / dynamic types of languages can run.

> It seems to me the only reason made up to justify
>    such use of .NET was to provide a slightly better look&feel and
>    better integrations to other parts of MS Windows environment to
>    attract 'new users'.  You need to realize how tiny such a thing
>    is considering the drawbacks of (1) duplicated codes/efforts that
>    will be abandoned as soon as we switch to ecell4, (2) a danger of
>    branching of the code and the development organization, (3) a
>    significantly less efficient use of human/institutional/financial
>    resources given to the ecell project.  (4) confusing users.

These are somewhat pointless; the mentioned side-effects are not
caused by the architecture, but the arrangement of the project.
Therefore I don't think being stick to Python / C++ / GTK would have
resulted in a better situation.

>    What we should have learned from the failure of the E-Cell 2 project
>    was how unthoughtful architectural decisions and political
>    interferences can demolish sound development and success of
>    software projects and how miserable it can be.

It looks like it was not you that made the decision about architecture
and so you thought you could make it better. Could we really dismiss
all the passage that simply?

>    What we need to do now is to think hard how this can be made
>    more constructive.  A good portion of E-Cell development is
>    being run thanks to fundings that come from Japanese government.
>    It's about two years since I moved to California.
>    One thing I think Japanese science may need to learn from
>    America is how agile people here make appropriate maneuvers
>    once they know they were running into a wrong direction.
>    That's what we need to learn here.

Got to do stuff in a more constructive way -- where I fully agree. I
think we should be more flexible at our thought, an pay attention to
what each other is doing without dismissing it stereotypically. With
regards to the latter issue I thought of a different reasoning about
this, but I'd like to tell you this one elsewhere as it's going  to be
off-topic.

> - C-Python vs CLR runtimes;  I couldn't get your point.
>    There is no point in comparing such different
>    architectures of Python VM and of C# VM.  C# should be compared
>    to Java.  Python is in the same world as Ruby or Perl.
>    Nevertheless, you understand any CLR languages are
>    not our option because with them we are not able to achieve the
>    level of portability we decided to need.

Although I'm not persist on CLR, I mentioned just for an example of a
VM architecture in the first place,  what do you think makes the CLR
less portable in this context?

Regards,
Moriyoshi

-- 
Moriyoshi Koizumi <mor...@gm...>
(also reachable on <mo...@sf...>)

- Languages;   We need to keep in mind why we want to mix
   languages in the first place.  There is one and only one
   reason, that is, compiled languages that are fast enough for
   doing high performance numerical simulation are almost always
   too technical, complicated, overkill and thus less productive
   for frontend programming and user scripting.  When you talk
   about this you need to always remember there is
   absolutely no other reasons.

   For this very reason, the combination must be a statically
   typed, natively compiled system language and a dynamic
   scripting language.  For this very reason, the combination
   used in E-Cell 2, C++/Java via C/JNI was nothing but
   ridiculous.  For this reason, none of C++/C#, Java/Ruby nor
   C#/Perl make sense for our particular case.  But C++/Python does.

   Our system language must be C++ because it must
   be transparently compatible to C to utilize tons of high quality
   numerical computation code written in the past twenty years
   available out there, and must support object orientation to
   cope with the complexity of E-Cell object model.  Competitors
   in this area may include Objective-C and D, but
   the former doesn't run as fast as C++, and D is still premature.

   Our frontend language is not Ruby because it is not comparable in
   terms of the scale of user community both in general and scientific
   computing, and thus yet to achieve the critical mass that makes us
   safe to rely on it and furthermore, lacks a number of third party
   modules important for us.   I cannot say I would expect for sure
   that the Ruby/Perl/C# scientific computing communities will be still
   actively alive in 2017, but Python's surely will be.

   This is actually a perfect time to rethink about this when
   we have a potential opportunity to remake everything towards ecell4.
   I'm open to any possibilities and would like to discuss if there
   can be better possible architectures.


 > Much like I find
 > myself more comfortable with my native tongue when I communicate,
 > there should be a certain number of people who prefer a grafical user
 > interface no matter how *competent* they are.

- I don't think I made even a word that can be taken as I'm opposed to
   GUI at all.  GUI is essential in providing users with a cognitive
   support when they need to handle a large amount of dynamically
   changing data set in simulation.   There is no doubt about it.  We
   keep investing a good amount of efforts to this area.

   What I'm sad about is simply that the E-Cell IDE project is repeating
   the mistake E-Cell 2 made.  Not only that its fundamental technical
   architecture is wrong, but also is it developing a wrong set of
   features to wrong hypothetical users that are nonexistent.

   One, there is not such a thing like 'software for novices' in science.
   There is no Mathematica or Matlab for 'non-experts' or students.
   One needs to learn an appropriate set of skills to do things
   if what's done needs to be called a scientific achievement.

   Two, if so, E-Cell IDE's users must not be limited to what you call
   'novices'.  However, then, the contradiction is E-Cell IDE built
   within the .NET environment cannot become or replace E-Cell's
   main modeling environment because it's not portable to
   at least two of our most important target platforms (OSX and
   linux).  (Don't mention Mono here, it's for running something
   that was already built in C#, and not for making new cross
   platform stuff)  It seems to me the only reason made up to justify
   such use of .NET was to provide a slightly better look&feel and
   better integrations to other parts of MS Windows environment to
   attract 'new users'.  You need to realize how tiny such a thing
   is considering the drawbacks of (1) duplicated codes/efforts that
   will be abandoned as soon as we switch to ecell4, (2) a danger of
   branching of the code and the development organization, (3) a
   significantly less efficient use of human/institutional/financial
   resources given to the ecell project.  (4) confusing users.

   What we should have learned from the failure of the E-Cell 2 project
   was how unthoughtful architectural decisions and political
   interferences can demolish sound development and success of
   software projects and how miserable it can be.   I was against
   ecell2 and predicted the unsuccessful consequence
   from the very beginning in 1999, but I was not politically mighty
   enough at the time.   This time, it was partly my failure, again,
   to allow running the E-Cell IDE project from
   the wrong start point towards the wrong goal.  I was in the
   process of moving from Japan to California and couldn't pay
   much attentions to anything else.

   An indication of such wrong architecture is your and MSS folks'
   having hard time trying to run ecell3 on the new platform.
   E-Cell 2 developers had a similar trouble, resulted in
   much longer development time than planned, poor performance
   and poor maintainability.

   What we need to do now is to think hard how this can be made
   more constructive.  A good portion of E-Cell development is
   being run thanks to fundings that come from Japanese government.
   It's about two years since I moved to California.
   One thing I think Japanese science may need to learn from
   America is how agile people here make appropriate maneuvers
   once they know they were running into a wrong direction.
   That's what we need to learn here.


- C-Python vs CLR runtimes;  I couldn't get your point.
   There is no point in comparing such different
   architectures of Python VM and of C# VM.  C# should be compared
   to Java.  Python is in the same world as Ruby or Perl.
   Nevertheless, you understand any CLR languages are
   not our option because with them we are not able to achieve the
   level of portability we decided to need.

- What I talked about was GTK's object system built on top of C.


-sha


>> All this boils down to two questions that we discussed in depth
>> five years ago, but it's good to repeat it here for new people
>> like you, Petteri and Nathan.  The questions are why we use that
>> particular combination of C++ and Python, and for whom we are
>> developing E-Cell.
>>
>> I have solid answers for both.  For the C++/Python question;
>> there is not a better solution considering the nature of our
>> problem.  The bottom line in ecell3's decision to mix languages
>> was to achieve a first-class performance in numerical computation,
>> a full-featured, highly extensible frontend environment, and
>> good portability to our target platforms at the same time.
> 
> In regard to combinations, there are lots of ones; members of such one
> could be C++ and Ruby. I think as long as the targeted languages are
> portable and good at calculation-intensive computing the first
> requisite can always be fulfilled. Probably I'm missing something
> though.
> 
>> Given that we couldn't find much use of highly flexible
>> E-Cell Micro Core architecture in E-Cell 3, we are currently
>> planning to make this coupling between the languages even tighter.
>> If you think you have better ideas let's discuss about it here,
>> but I think I considered all combinations of available languages
>> pretty thoroughly before reaching the conclusion.
> 
> That said, I can't always say Python is superior over others in all
> the contexts we handle by the software. For example, there is likely a
> situation where O'Caml is better for modeling. (Don't take this so
> serious; It's just an example. :-)
> 
>> Second question; we develop E-Cell for computational biologists
>> who have an ability to become computational scientists or trained
>> to be so.
> 
> That's true.
> 
>> Naturally our emphases are on providing flexible,
>> highly scriptable, high performance platform that might not
>> be something plain molecular biologists may learn everything about
>> it within three days, but must be something someone with a higher
>> computer literacy will feel perfectly comfortable in their
>> everyday projects.
> 
> I think that is the point you and me would go differently. If we look
> at e-cell merely as a tool for biologists in general, it should be
> accessible in various ways. Good scriptability may be among them. But
> again, in which form could one feel comfortable? Much like I find
> myself more comfortable with my native tongue when I communicate,
> there should be a certain number of people who prefer a grafical user
> interface no matter how *competent* they are.
> 
> And having that said, I think the IDE has not just been made for
> people who are not that skillful in computer operation, but even to be
> at its least eye-catchy for wider audiences, part of who are enough
> competent to enhance the set of our softwares, are possibly plain
> computer engineers, not necessarily trained as biology researchers
> (I'd say, like me :)
> 
>> By pursuing this direction, we'll eventually
>> reach at the point that it will be widely useful for everyone.
>> Our target platforms are, naturally, what dominates the world
>> of computational sciences; primarily Linux, OSX, and then
>> Microsoft Windows.    The reality is 90% of important scientific
>> activities are done by top 5%.  Developing something for 'novice'
>> users is an important mission, but you can expect little if you
>> expect feedbacks and contributions from competent users.
> 
> Virtually a software without proper engineering could not be so
> successful where the term "engineering" includes testing, release
> management, issue handling and anything that are fundamental but not
> directly involved in the purpose of the software itself. And I tend to
> disagree we can expect the "top 5%" could do that much because most of
> their activities in their studies are not relevant to these.
> Furthermore, partly from my experience, feedbacks we find useful come
> from a certain ratio of users overall whatever background they have.
> 
>> I don't want to mention every relevant points here, but here are
>> some from your previous message;
>> - Your trouble about CLR; sad to know that.  All what I can say is
>>    we should have learned something from the failure of E-Cell 2.
> 
> I personally think what we should learn from the former attempt is
> that the people involved in the project didn't exactly know what they
> do and how they do each other, and the reason behind this, was lack of
> interest. Sorry if I take it just wrong.
> 
>> - Python's runtime; could you elaborate a bit about the problem
>>    you are having?
> 
> It's a rather general argument instead of my problem. Firstly, what I
> was referring to is C-Python. C-Python has a monolithic bytecode
> interpreter, which I believe is not suitable for parallel computing
> due to its primary goal. In this point I would say something like CLR
> is far better at this because the language expressions and the runtime
> are separate in design, and thus you can make it scalable by replacing
> the runtime.
> 
>> - APIs in C or C++; I don't think ABI compatibility is that important
>>    for us.  E-Cell3's libemc/pyecs provides a flat, functional APIs
>>    that could easily mapped to gtk-style object oriented API functions
>>    in C.  However, this will entirely replaced with a full object
>>    oriented API layer in E-Cell 4.
> 
> GTK stuff is an irrelevant example here, since the GTK frontend and
> the libecs backends are connected at the Python layer where every
> objects get mapped to the Python's object system, not at the lower
> layer between Python and C++ that are glued together with
> boost-python.  What I was talking about is such C++ dependency.
> 
> Regards,
> Moriyoshi
> 

> All this boils down to two questions that we discussed in depth
> five years ago, but it's good to repeat it here for new people
> like you, Petteri and Nathan.  The questions are why we use that
> particular combination of C++ and Python, and for whom we are
> developing E-Cell.
>
> I have solid answers for both.  For the C++/Python question;
> there is not a better solution considering the nature of our
> problem.  The bottom line in ecell3's decision to mix languages
> was to achieve a first-class performance in numerical computation,
> a full-featured, highly extensible frontend environment, and
> good portability to our target platforms at the same time.

In regard to combinations, there are lots of ones; members of such one
could be C++ and Ruby. I think as long as the targeted languages are
portable and good at calculation-intensive computing the first
requisite can always be fulfilled. Probably I'm missing something
though.

> Given that we couldn't find much use of highly flexible
> E-Cell Micro Core architecture in E-Cell 3, we are currently
> planning to make this coupling between the languages even tighter.
> If you think you have better ideas let's discuss about it here,
> but I think I considered all combinations of available languages
> pretty thoroughly before reaching the conclusion.

That said, I can't always say Python is superior over others in all
the contexts we handle by the software. For example, there is likely a
situation where O'Caml is better for modeling. (Don't take this so
serious; It's just an example. :-)

> Second question; we develop E-Cell for computational biologists
> who have an ability to become computational scientists or trained
> to be so.

That's true.

> Naturally our emphases are on providing flexible,
> highly scriptable, high performance platform that might not
> be something plain molecular biologists may learn everything about
> it within three days, but must be something someone with a higher
> computer literacy will feel perfectly comfortable in their
> everyday projects.

I think that is the point you and me would go differently. If we look
at e-cell merely as a tool for biologists in general, it should be
accessible in various ways. Good scriptability may be among them. But
again, in which form could one feel comfortable? Much like I find
myself more comfortable with my native tongue when I communicate,
there should be a certain number of people who prefer a grafical user
interface no matter how *competent* they are.

And having that said, I think the IDE has not just been made for
people who are not that skillful in computer operation, but even to be
at its least eye-catchy for wider audiences, part of who are enough
competent to enhance the set of our softwares, are possibly plain
computer engineers, not necessarily trained as biology researchers
(I'd say, like me :)

> By pursuing this direction, we'll eventually
> reach at the point that it will be widely useful for everyone.
> Our target platforms are, naturally, what dominates the world
> of computational sciences; primarily Linux, OSX, and then
> Microsoft Windows.    The reality is 90% of important scientific
> activities are done by top 5%.  Developing something for 'novice'
> users is an important mission, but you can expect little if you
> expect feedbacks and contributions from competent users.

Virtually a software without proper engineering could not be so
successful where the term "engineering" includes testing, release
management, issue handling and anything that are fundamental but not
directly involved in the purpose of the software itself. And I tend to
disagree we can expect the "top 5%" could do that much because most of
their activities in their studies are not relevant to these.
Furthermore, partly from my experience, feedbacks we find useful come
from a certain ratio of users overall whatever background they have.

> I don't want to mention every relevant points here, but here are
> some from your previous message;
> - Your trouble about CLR; sad to know that.  All what I can say is
>    we should have learned something from the failure of E-Cell 2.

I personally think what we should learn from the former attempt is
that the people involved in the project didn't exactly know what they
do and how they do each other, and the reason behind this, was lack of
interest. Sorry if I take it just wrong.

> - Python's runtime; could you elaborate a bit about the problem
>    you are having?

It's a rather general argument instead of my problem. Firstly, what I
was referring to is C-Python. C-Python has a monolithic bytecode
interpreter, which I believe is not suitable for parallel computing
due to its primary goal. In this point I would say something like CLR
is far better at this because the language expressions and the runtime
are separate in design, and thus you can make it scalable by replacing
the runtime.

> - APIs in C or C++; I don't think ABI compatibility is that important
>    for us.  E-Cell3's libemc/pyecs provides a flat, functional APIs
>    that could easily mapped to gtk-style object oriented API functions
>    in C.  However, this will entirely replaced with a full object
>    oriented API layer in E-Cell 4.

GTK stuff is an irrelevant example here, since the GTK frontend and
the libecs backends are connected at the Python layer where every
objects get mapped to the Python's object system, not at the lower
layer between Python and C++ that are glued together with
boost-python.  What I was talking about is such C++ dependency.

Regards,
Moriyoshi

-- 
Moriyoshi Koizumi <mor...@gm...>
(also reachable on <mo...@sf...>)

mori,


All this boils down to two questions that we discussed in depth
five years ago, but it's good to repeat it here for new people
like you, Petteri and Nathan.  The questions are why we use that
particular combination of C++ and Python, and for whom we are
developing E-Cell.

I have solid answers for both.  For the C++/Python question;
there is not a better solution considering the nature of our
problem.  The bottom line in ecell3's decision to mix languages
was to achieve a first-class performance in numerical computation,
a full-featured, highly extensible frontend environment, and
good portability to our target platforms at the same time.
Given that we couldn't find much use of highly flexible
E-Cell Micro Core architecture in E-Cell 3, we are currently
planning to make this coupling between the languages even tighter.
If you think you have better ideas let's discuss about it here,
but I think I considered all combinations of available languages
pretty thoroughly before reaching the conclusion.

Second question; we develop E-Cell for computational biologists
who have an ability to become computational scientists or trained
to be so.  Naturally our emphases are on providing flexible,
highly scriptable, high performance platform that might not
be something plain molecular biologists may learn everything about
it within three days, but must be something someone with a higher
computer literacy will feel perfectly comfortable in their
everyday projects.  By pursuing this direction, we'll eventually
reach at the point that it will be widely useful for everyone.
Our target platforms are, naturally, what dominates the world
of computational sciences; primarily Linux, OSX, and then
Microsoft Windows.    The reality is 90% of important scientific
activities are done by top 5%.  Developing something for 'novice'
users is an important mission, but you can expect little if you
expect feedbacks and contributions from competent users.

I don't want to mention every relevant points here, but here are
some from your previous message;
- Your trouble about CLR; sad to know that.  All what I can say is
   we should have learned something from the failure of E-Cell 2.
- Python's runtime; could you elaborate a bit about the problem
   you are having?
- APIs in C or C++; I don't think ABI compatibility is that important
   for us.  E-Cell3's libemc/pyecs provides a flat, functional APIs
   that could easily mapped to gtk-style object oriented API functions
   in C.  However, this will entirely replaced with a full object
   oriented API layer in E-Cell 4.



sha







> Shafi,
> 
> Thank you for clarifying the current status of the project.
> 
> 2007/3/20, Koichi Takahashi <sh...@sf...>:
>> * First of all, all what we need to keep thinking about is how
>>    we can steer the whole E-Cell development towards the right
>>    direction, in the way most efficient.  With limited resources.
>>    Most important is to get and keep a good focus on what really
>>    needs to be done.   In cell simulation, there is no doubt that
>>    the frontier is arising in the area of spatial simulation and
>>    dynamic structure, and accompanying parallelism.
> 
> Definitely right. Yet I tend to think considering the resource to be
> limited, partly because the ongoing work is hard to be paralleled,
> would lead to limit the potential extent of the resource availability. As
> e-cell has grown a notable opensource project among others in systems
> biology it can gather far more interests of competent people out
> there, just if there are more opportunities of exposure to the
> researchers and developers.
> That's the reason I'm keen on the IDE development now.
> 
>>    I appreciate the windows port and IDE stuff, but there are already
>>    tons of software of that kind. In the workshop in January we all
>>    agreed that continuing versions of ecell must be cross-platform,
>>    and this must be accomplished with a unified code base.
> 
> When we think about portability in terms of being cross-platform,
> I think we should also keep interoperability between the
> architectures in mind, kind of what is between Python and Perl, as
> well. Because that will give two benefits; one is the reusability of
> e-cell itself, and the other is the reusability of another remarkable
> software components I would say greatly save our time.
> 
>> * So, if you think tweaking vvector is the best way for you
>>    please do it, keeping in mind above and what I mentioned in
>>    the previous message.
> 
> For now I don't think I need much help from other e-cell developers
> for this, so if the rework is a waste of time in reality, what could
> be wasted should be just mine. So please don't worry about it. What I
> want to make sure is that anyone is not bothered by what I'm going to
> do, as it will be a major change on the current codebase.
> 
>>    For that, now that we have Python and its efficient data handling
>>    libraries like numpy, we are allowed to simply pursue
>>    simplicity of the design.   Here in California I've been working
>>    on a high-performance brownian dynamics code, that will eventually
>>    be part of ecell, in Python/C++.  Part of the code needs to do
>>    an O(N^2) operation on a huge array to calculate a distance matrix
>>    for particle positions, but Python/numpy runs pretty fast.
> 
> Well, while this might not be a matter you need to begin to think
> about, Numpy had been troublesome when the IDE team were trying to fit
> the libecs to the CLR environment. Although Python's basic types are
> easily convertible to those of CLR, non-scalar types such as matrices
> needed a much effort. Eventually I had to use notorious COM to glue
> them. Sigh.
> 
>>    Plus, if the next generation ecell's main focus will be spatial sim,
>>    CPU cycles required to proceed a single step of simulation will be
>>    several orders of magnitude larger; meaning that logging overhead
>>    could have much less impact on overall performance.  Furthermore,
>>    by keeping the data array on the frontendside, we can avoid
>>    the unnecessary memcpy we still have to do in ecell3 that occurs when
>>    the data is passed from libecs to Python through pyecs.
> 
> More stuff being done in Python could make it less scalable since the
> runtime environment would be heavily dependent on the Python then.
> Python is a neat scripting language, but I couldn't necessarily say
> the same for the runtime.
> 
> BTW, if Numpy was a thin wrapper of a well-defined C library that
> implements the functionality, then the performance drawback in data
> passing would be even less because objects could be accessed both from
> Python scripts and C++ codes with zero-copy (except for basic types,
> of course.)
> 
>> * Logging in ecell4 may be as simple as the following;  the C++
>>    backend defines a few API methods to register/remove/manage
>>    callback functions which are called when values of designated
>>    object properties change.  Callback functions may simply push back
>>    the value with a time stamp to a log file,
>>    or may poke a function in a GUI component to update the display,
>>    or whatever.   As part of the standard Python ecell library,
>>    standard data log processing functions may be defined.
> 
> Sounds great. If the API set is much simpler than now, I want C API
> instead of C++ because C++ lacks interoperability when it comes to the
> ABI compatibility between compilers and languages. For example, C API
> would enable a DLL built with MinGW to be used in MSVC without
> recompile. Plus, better connectivity with other languages that have
> different type systems such as Objective-C.
> 
>> * I and Nathan are starting the development of ecell4 core, hopefully
>>    from April as soon as the contract between Keio and MSI is settled.
>>    While we are still working on more detailed specifications and plans,
>>    please see pages below;
>>
>> http://www.e-cell.org/developers/e-cell-4/e-cell4-core-design/
>> http://www.e-cell.org/developers/e-cell-4/coding-standard/
>> http://www.e-cell.org/ecell4workshop/workshop-results/schedule-minutes
> 
> Thanks for the pointer. Can't wait to see the working code! Keep up the work.
> 
> Regards,
> Moriyoshi
> 

Shafi,

Thank you for clarifying the current status of the project.

2007/3/20, Koichi Takahashi <sh...@sf...>:
>
> * First of all, all what we need to keep thinking about is how
>    we can steer the whole E-Cell development towards the right
>    direction, in the way most efficient.  With limited resources.
>    Most important is to get and keep a good focus on what really
>    needs to be done.   In cell simulation, there is no doubt that
>    the frontier is arising in the area of spatial simulation and
>    dynamic structure, and accompanying parallelism.

Definitely right. Yet I tend to think considering the resource to be
limited, partly because the ongoing work is hard to be paralleled,
would lead to limit the potential extent of the resource availability. As
e-cell has grown a notable opensource project among others in systems
biology it can gather far more interests of competent people out
there, just if there are more opportunities of exposure to the
researchers and developers.
That's the reason I'm keen on the IDE development now.

>    I appreciate the windows port and IDE stuff, but there are already
>    tons of software of that kind. In the workshop in January we all
>    agreed that continuing versions of ecell must be cross-platform,
>    and this must be accomplished with a unified code base.

When we think about portability in terms of being cross-platform,
I think we should also keep interoperability between the
architectures in mind, kind of what is between Python and Perl, as
well. Because that will give two benefits; one is the reusability of
e-cell itself, and the other is the reusability of another remarkable
software components I would say greatly save our time.

> * So, if you think tweaking vvector is the best way for you
>    please do it, keeping in mind above and what I mentioned in
>    the previous message.

For now I don't think I need much help from other e-cell developers
for this, so if the rework is a waste of time in reality, what could
be wasted should be just mine. So please don't worry about it. What I
want to make sure is that anyone is not bothered by what I'm going to
do, as it will be a major change on the current codebase.

>    For that, now that we have Python and its efficient data handling
>    libraries like numpy, we are allowed to simply pursue
>    simplicity of the design.   Here in California I've been working
>    on a high-performance brownian dynamics code, that will eventually
>    be part of ecell, in Python/C++.  Part of the code needs to do
>    an O(N^2) operation on a huge array to calculate a distance matrix
>    for particle positions, but Python/numpy runs pretty fast.

Well, while this might not be a matter you need to begin to think
about, Numpy had been troublesome when the IDE team were trying to fit
the libecs to the CLR environment. Although Python's basic types are
easily convertible to those of CLR, non-scalar types such as matrices
needed a much effort. Eventually I had to use notorious COM to glue
them. Sigh.

>    Plus, if the next generation ecell's main focus will be spatial sim,
>    CPU cycles required to proceed a single step of simulation will be
>    several orders of magnitude larger; meaning that logging overhead
>    could have much less impact on overall performance.  Furthermore,
>    by keeping the data array on the frontendside, we can avoid
>    the unnecessary memcpy we still have to do in ecell3 that occurs when
>    the data is passed from libecs to Python through pyecs.

More stuff being done in Python could make it less scalable since the
runtime environment would be heavily dependent on the Python then.
Python is a neat scripting language, but I couldn't necessarily say
the same for the runtime.

BTW, if Numpy was a thin wrapper of a well-defined C library that
implements the functionality, then the performance drawback in data
passing would be even less because objects could be accessed both from
Python scripts and C++ codes with zero-copy (except for basic types,
of course.)

> * Logging in ecell4 may be as simple as the following;  the C++
>    backend defines a few API methods to register/remove/manage
>    callback functions which are called when values of designated
>    object properties change.  Callback functions may simply push back
>    the value with a time stamp to a log file,
>    or may poke a function in a GUI component to update the display,
>    or whatever.   As part of the standard Python ecell library,
>    standard data log processing functions may be defined.

Sounds great. If the API set is much simpler than now, I want C API
instead of C++ because C++ lacks interoperability when it comes to the
ABI compatibility between compilers and languages. For example, C API
would enable a DLL built with MinGW to be used in MSVC without
recompile. Plus, better connectivity with other languages that have
different type systems such as Objective-C.

> * I and Nathan are starting the development of ecell4 core, hopefully
>    from April as soon as the contract between Keio and MSI is settled.
>    While we are still working on more detailed specifications and plans,
>    please see pages below;
>
> http://www.e-cell.org/developers/e-cell-4/e-cell4-core-design/
> http://www.e-cell.org/developers/e-cell-4/coding-standard/
> http://www.e-cell.org/ecell4workshop/workshop-results/schedule-minutes

Thanks for the pointer. Can't wait to see the working code! Keep up the work.

Regards,
Moriyoshi

-- 
Moriyoshi Koizumi <mor...@gm...>
(also reachable on <mo...@sf...>)

* First of all, all what we need to keep thinking about is how
   we can steer the whole E-Cell development towards the right
   direction, in the way most efficient.  With limited resources.
   Most important is to get and keep a good focus on what really
   needs to be done.   In cell simulation, there is no doubt that
   the frontier is arising in the area of spatial simulation and
   dynamic structure, and accompanying parallelism.
   I appreciate the windows port and IDE stuff, but there are already
   tons of software of that kind. In the workshop in January we all
   agreed that continuing versions of ecell must be cross-platform,
   and this must be accomplished with a unified code base.
   When resources and time is limited, we have to think deeply about
   this.  Everything needs to be organized in this spirit.

* So, if you think tweaking vvector is the best way for you
   please do it, keeping in mind above and what I mentioned in
   the previous message.

* Yes, data logging/storage/processing will be done in Python.
   Come to think about that, the reason I designed ecell 1/3 in the
   way that data is logged and stored in the backend was mainly due
   to the fact that PCs at that time were not fast enough.  What's
   sacrificed was simplicity/maintainability/flexibility of the
   architecture. The only thing we got was some degree of speed.
   For that, now that we have Python and its efficient data handling
   libraries like numpy, we are allowed to simply pursue
   simplicity of the design.   Here in California I've been working
   on a high-performance brownian dynamics code, that will eventually
   be part of ecell, in Python/C++.  Part of the code needs to do
   an O(N^2) operation on a huge array to calculate a distance matrix
   for particle positions, but Python/numpy runs pretty fast.
   Plus, if the next generation ecell's main focus will be spatial sim,
   CPU cycles required to proceed a single step of simulation will be
   several orders of magnitude larger; meaning that logging overhead
   could have much less impact on overall performance.  Furthermore,
   by keeping the data array on the frontendside, we can avoid
   the unnecessary memcpy we still have to do in ecell3 that occurs when
   the data is passed from libecs to Python through pyecs.

* Logging in ecell4 may be as simple as the following;  the C++
   backend defines a few API methods to register/remove/manage
   callback functions which are called when values of designated
   object properties change.  Callback functions may simply push back
   the value with a time stamp to a log file,
   or may poke a function in a GUI component to update the display,
   or whatever.   As part of the standard Python ecell library,
   standard data log processing functions may be defined.

* I and Nathan are starting the development of ecell4 core, hopefully
   from April as soon as the contract between Keio and MSI is settled.
   While we are still working on more detailed specifications and plans,
   please see pages below;

http://www.e-cell.org/developers/e-cell-4/e-cell4-core-design/
http://www.e-cell.org/developers/e-cell-4/coding-standard/
http://www.e-cell.org/ecell4workshop/workshop-results/schedule-minutes


sha



> 2007/3/20, Koichi Takahashi <sh...@sf...>:
>> Mori,
>>
>> You're right.  We have been talking about rewriting VVector
>> since at least three years ago.
>>
>> Some points from me:
>>
>> - E-Cell3's VVector stuff is a legacy component inherited from
>>    old ecell1, written in an old fashioned C++, troublesome to
>>    maintain, and a major source of complaints from users (tmpfiles
>>    easily fill up /tmp).
> 
> That's my thought. Besides no point to get the rather high-level array
> manipulator bothered by the available disk space :)
> 
>> - We have been discussing about replacing the vvector mechanism with
>>    something more modern.  However, in E-Cell 4, logging and data
>>    storage will be done at the frontend level.  The C++ backend will
>>    only provide callbacks.
> 
> If so, they will be implemented in Python altogether? While I
> personally don't think everyone could get used to Python then, I'm one
> who is under the impression building such complex object relationships
> needs to be more flexible somehow, not in a way everything is written
> in settings, which is the choice of strict-typed, less dynamic
> languages like Java and I found just awkward.
> 
>> - If so, I'm not sure if there's an immense need to do such a major
>>    efforts to entirely rewrite an entire functional component that
>>    will be completely abandoned in the next version.   It might have
>>    made sense two years ago, but not now.
> 
> Well, I expected the words indeed. My aim here is get the e-cell IDE
> under the heavy development out the door as quickly as possible, which
> will (should) at least be usable wih the next generation of e-cell and
> the plan includes porting the IDE (written vastly in C#) to various
> platforms as significantly the compatibility of Mono's Windows Form
> implementation has been improved these days. For me e-cell3 still
> looks fine and usable anyway and I'm going to stick to it for a while.
> That could also help the e-cell4 development, I think.
> 
>> - I suggest the following.  Dropping the osif header and reorganize
>>    functions as part of vvector itself sounds fine.
>>    Reimplementation of the file IO may be an overkill at this time when
>>    we are ceasing adding new functions to ecell3, as
>>    this may introduce some bugs and thus a need for redoing extensive
>>    testing of the whole thing.
> 
> Actually e-cell3 still got a variety of minor bugs, each of which
> isn't that harmful to the entire system. Some of them can be fixed
> well by a little work of refactoring and that's the motive of my
> proposal. I think VVector deserves the effort as the function of
> VVector is pretty much simple and apparently less bug prone.
> 
>> - Instead, I suppose you may be interested in take a major part in
>>    designing and implementing the new logging infrastructure for the
>>    new version.
> 
> Interested, but what is actually going to be like? Please give me some
> more input.
> 
> Thanks,
> Moriyoshi
> 

2007/3/20, Koichi Takahashi <sh...@sf...>:
> Mori,
>
> You're right.  We have been talking about rewriting VVector
> since at least three years ago.
>
> Some points from me:
>
> - E-Cell3's VVector stuff is a legacy component inherited from
>    old ecell1, written in an old fashioned C++, troublesome to
>    maintain, and a major source of complaints from users (tmpfiles
>    easily fill up /tmp).

That's my thought. Besides no point to get the rather high-level array
manipulator bothered by the available disk space :)

> - We have been discussing about replacing the vvector mechanism with
>    something more modern.  However, in E-Cell 4, logging and data
>    storage will be done at the frontend level.  The C++ backend will
>    only provide callbacks.

If so, they will be implemented in Python altogether? While I
personally don't think everyone could get used to Python then, I'm one
who is under the impression building such complex object relationships
needs to be more flexible somehow, not in a way everything is written
in settings, which is the choice of strict-typed, less dynamic
languages like Java and I found just awkward.

> - If so, I'm not sure if there's an immense need to do such a major
>    efforts to entirely rewrite an entire functional component that
>    will be completely abandoned in the next version.   It might have
>    made sense two years ago, but not now.

Well, I expected the words indeed. My aim here is get the e-cell IDE
under the heavy development out the door as quickly as possible, which
will (should) at least be usable wih the next generation of e-cell and
the plan includes porting the IDE (written vastly in C#) to various
platforms as significantly the compatibility of Mono's Windows Form
implementation has been improved these days. For me e-cell3 still
looks fine and usable anyway and I'm going to stick to it for a while.
That could also help the e-cell4 development, I think.

> - I suggest the following.  Dropping the osif header and reorganize
>    functions as part of vvector itself sounds fine.
>    Reimplementation of the file IO may be an overkill at this time when
>    we are ceasing adding new functions to ecell3, as
>    this may introduce some bugs and thus a need for redoing extensive
>    testing of the whole thing.

Actually e-cell3 still got a variety of minor bugs, each of which
isn't that harmful to the entire system. Some of them can be fixed
well by a little work of refactoring and that's the motive of my
proposal. I think VVector deserves the effort as the function of
VVector is pretty much simple and apparently less bug prone.

>
> - Instead, I suppose you may be interested in take a major part in
>    designing and implementing the new logging infrastructure for the
>    new version.

Interested, but what is actually going to be like? Please give me some
more input.

Thanks,
Moriyoshi

-- 
Moriyoshi Koizumi <mor...@gm...>
(also reachable on <mo...@sf...>)

Mori,

You're right.  We have been talking about rewriting VVector
since at least three years ago.

Some points from me:

- E-Cell3's VVector stuff is a legacy component inherited from
   old ecell1, written in an old fashioned C++, troublesome to
   maintain, and a major source of complaints from users (tmpfiles
   easily fill up /tmp).

- We have been discussing about replacing the vvector mechanism with
   something more modern.  However, in E-Cell 4, logging and data
   storage will be done at the frontend level.  The C++ backend will
   only provide callbacks.

- If so, I'm not sure if there's an immense need to do such a major
   efforts to entirely rewrite an entire functional component that
   will be completely abandoned in the next version.   It might have
   made sense two years ago, but not now.

- I suggest the following.  Dropping the osif header and reorganize
   functions as part of vvector itself sounds fine.
   Reimplementation of the file IO may be an overkill at this time when
   we are ceasing adding new functions to ecell3, as
   this may introduce some bugs and thus a need for redoing extensive
   testing of the whole thing.

- Instead, I suppose you may be interested in take a major part in
   designing and implementing the new logging infrastructure for the
   new version.


sha



> Hi all,
> 
> First I would like to say thanks to those at the last month's
> workshop, who (patiently) had an interest in me, in a welcome manner.
> I hope it's not too late.
> 
> Okay, then start to discuss the main issue.
> 
> In a second-bout effort to adapt ecell3 to the MS Visual Studio
> builds, I found the osif functions are arranged quite ad-hoc and used
> only in vvector. Then I looked into the vvector code, see lots of
> pieces that are mixtures of a thin logic and I/Os, apparently
> hard-to-separate as long as they are. In addition, I think the vvector
> can be more efficiently with mmap().
> 
> So, my proposals are:
> 1. Drop osif functions. They are now vvector-specific and it doesn't
> make sense to have them as part of the internal APIs.
> 2. Take the I/O out of the vvector classes and reimplement it as a
> class of block I/O abstraction so it will incorporate the
> functionality of what was osif.
> 
> Any opinions would be appreciated.
> 

Hi all,

First I would like to say thanks to those at the last month's
workshop, who (patiently) had an interest in me, in a welcome manner.
I hope it's not too late.

Okay, then start to discuss the main issue.

In a second-bout effort to adapt ecell3 to the MS Visual Studio
builds, I found the osif functions are arranged quite ad-hoc and used
only in vvector. Then I looked into the vvector code, see lots of
pieces that are mixtures of a thin logic and I/Os, apparently
hard-to-separate as long as they are. In addition, I think the vvector
can be more efficiently with mmap().

So, my proposals are:
1. Drop osif functions. They are now vvector-specific and it doesn't
make sense to have them as part of the internal APIs.
2. Take the I/O out of the vvector classes and reimplement it as a
class of block I/O abstraction so it will incorporate the
functionality of what was osif.

Any opinions would be appreciated.

-- 
Moriyoshi Koizumi <mor...@gm...>
(also reachable on <mo...@sf...>)

Right.  And even if it were a third-party, it wouldn't affect
portability at the end user level only concerns binary packages.

sha

> Hei,
> 
> Ok. Now I see that pyunit is part of python's standard libraries since 
> 2.1. Therefore using it does not introduce an extra dependency in the 
> build platform. We can implement all the tests using it.
> 
> -- 
> Petteri
> 
> 
> On 3/8/07, *Koichi Takahashi* <sh...@sf... 
> <mailto:sh...@sf...>> wrote:
> 
>     Petteri,
> 
>     Very nice to know you are starting to work on testing suite.
> 
>     One important goal of such automated testing mechanism is
>     to be simple and extensive.   To this end, I suggest to
>     integrate everything as much as possible under pyUnit.
>     This should be simple to do and will save lots of efforts
>     and time.  You may need to spend an hour or two getting
>     used to pyUnit but this should pay well.
> 
>     The kind of tests you proposed that uses sample models
>     can be viewed as a kind of unit test that views ecell's
>     Session mechanism as a unit.
> 
>     sha
> 
> 
> 
>      > Hei,
>      >
>      > The models in doc/sample are very suitable for "smoke testing".
>     That is,
>      > after compiling the code, you could run "make test" to verify
>     that your
>      > runtime works and to check if any basic feature is broken. Suitable
>      > minimum criterium for each sample script is that it runs and
>     exits with
>      > zero if ok and  nonzero otherwise. With this kind of minimal test
>     suite
>      > in place, we can instruct users to do following when they install
>     ecell
>      > from sources.
>      >
>      > ./configure && make install && make test
>      >
>      > If anything in the environment is awfully wrong, it would surface
>     in the
>      > last "make test" phase. Which helps to pinpoint the trouble area,
>     saves
>      > everybody's time in support emails, and enables crude automatic
>     testing.
>      >
>      > The next level in testing should be unit and regression testing.
>     There
>      > we could implement checking the numerical accuracy of solvers and
>     such.
>      >
>      > In order to keep things simple, I would implement the "smoke
>     test" using
>      > simple makefile rules and selected models from doc/samples only. Unit
>      > and regressing tests are more complex and should be made with pyunit.
>      >
>      > I would propose that we update the models and READMEs in
>     doc/samples and
>      > make them all uniform. If anybody could just make a sample
>      > implementation with the desired calling conventions, e.g. the simple
>      > model, I could start working based on that.
>      >
>      > --
>      > Petteri
>      >
>      >
>      >
>      >>     *From: * Koichi Takahashi <sh...@sf...
>     <mailto:sh...@sf...>
>      >>     <mailto:sh...@sf... <mailto:sh...@sf...> >>
>      >>     *Date: * March 6, 2007 9:12:40 AM JST
>      >>     *To: * ka...@sf... <mailto:ka...@sf...>
>     <mailto:ka...@sf... <mailto:ka...@sf...> >,
>      >>     ece...@li...
>     <mailto:ece...@li...>
>      >>     <mailto:ece...@li...
>     <mailto:ece...@li...>>
>      >>     *Subject: * *Re: [Ecell-devel] doc/samples*
>      >>     *Reply-To: * ece...@li...
>     <mailto:ece...@li...>
>      >>     <mailto: ece...@li...
>     <mailto:ece...@li...>>
>      >>
>      >>     hi kaizu and petteri,
>      >>
>      >>
>      >>     Recently I had a chance to look at pyUnit.   I liked it.
>      >>     Perhaps you two could work together to implement make test
>      >>     based on it?
>      >>
>      >>     sha
>      >>
>      >>
>      >>>     Hi, Petteri!
>      >>>
>      >>>     I think that the samples in 'doc/sample' direcotry are for
>      >>>     helping "modelers"
>      >>>     to use DM classes(ex, ODE solvers) in em. They handle practical
>      >>>     cases, but are
>      >>>     not suited to testing. One of the reasons is that they are too
>      >>>     complex to have
>      >>>     an analytical solution.
>      >>>     They may be appropriate for checking only whether DM
>     classes work
>      >>>     or not.
>      >>>     But we need to design new test models for testing the
>     accuracy.
>      >>>
>      >>>     For example, about ODE solvers, a lot of test problems have
>     been
>      >>>     proposed.
>      >>>     One of the most classical sets is DETEST:
>      >>>
>      >>>     "Comparing Numerical Methods for Ordinary Differential
>     Equations"
>      >>>     by Hull, T.E. for non-stiff ODE
>      >>>     "Comparing Numerical Methods for Stiff Systems of ODEs"
>      >>>     by Enright, W.H.
>      >>>
>      >>>     That was designed for testing the efficiency of ODE
>     solvers, but
>      >>>     also includes
>      >>>     simple problems like:
>      >>>
>      >>>     dy/dt = -y
>      >>>     y(0)=1.0
>      >>>
>      >>>     -> y = y(0)*exp(-t)
>      >>>
>      >>>     If you need more information about it, I'll send you sample
>     scripts.
>      >>>     In the sample Python scritps, the results by ODE solvers
>     are compared
>      >>>     with the analytical solution.
>      >>>
>      >>>     The case for stochasitc solvers like Gillespie method are more
>      >>>     complicated
>      >>>     because it needs statistical analysis.
>      >>>
>      >>>
>      >>>     I don't know much about general form of test script. Could you
>      >>>     tell me the
>      >>>     specifications of input and output? (Is it enough to return
>     with
>      >>>     some exception
>      >>>     when the accuracy is not guaranteed?) Then, I'll modify sample
>      >>>     test scripts
>      >>>     to suite that.
>      >>>
>      >>>     Anyway, as you wrote, sample models in doc/sample directory
>      >>>     should also
>      >>>     include some sample scripts in it.
>      >>>
>      >>>     Thanks.
>      >>>
>      >>>
>      >>>     Kaizu
>      >>>
>      >>>     2006/12/17, Koichi Takahashi < sh...@e-...
>     <mailto:sh...@e-...>
>      >>>     <mailto:sh...@e-... <mailto:sh...@e-...>>>:
>      >>>>     Hei Petteri,
>      >>>>
>      >>>>     Great work.  Testing is important.   I appreciate it.
>      >>>>
>      >>>>     Two suggestions;
>      >>>>
>      >>>>     - Kazunari Kaizu may have made a simple test suite for ODE
>     solvers
>      >>>>        somewhere.  He might be able to pass it for you
>     incorporating
>      >>>>        it as part of yours.
>      >>>>
>      >>>>     - Satya, if some modules don't work on some platforms,
>     these should
>      >>>>        raise an exception when imported, not when called.  
>     We've got
>      >>>>        enough feedbacks from win users complaining they cannot run
>      >>>>     Session
>      >>>>        Manager.
>      >>>>
>      >>>>     sha
>      >>>>
>      >>>>
>      >>>>
>      >>>>
>      >>>>
>      >>>>>     Hi Petteri,
>      >>>>>
>      >>>>>     Thank you for your efforts. For Windows please use the newer
>      >>>>>     version of
>      >>>>>     E-Cell, which can be found at:
>      >>>>>    
>     http://prdownloads.sourceforge.net/ecell/ecell-3.1.105a-gtk%2Bpython.i386.exe?download
>      >>>>>     Currently, E-Cell does not support GA and SessionManager
>     on Windows
>      >>>>>     because we are lacking some essential Python modules for the
>      >>>>>     platform.
>      >>>>>
>      >>>>>     satya
>      >>>>>
>      >>>>>
>      >>>>>>     Hei,
>      >>>>>>
>      >>>>>>     In preparation to using `doc/samples' as test input data, I
>      >>>>>>     gave them
>      >>>>>>     a try on Wintel (ecell-3.1.103-gtk+python.i386.exe). Please
>      >>>>>>     see below
>      >>>>>>     for summary. Most of the samples don't have Python file
>     to run
>      >>>>>>     them
>      >>>>>>     from command line. I could probably conjure simple ones
>     on my own.
>      >>>>>>     However, the authors of `ga', `sessionmanager' and
>     `simple' should
>      >>>>>>     have a look at those and fix them. Or admin should
>     remove them
>      >>>>>>     altogether because such broken samples do no good and can be
>      >>>>>>     misleading in the worst case.
>      >>>>>>
>      >>>>>>     Please propose how to proceed.
>      >>>>>>
>      >>>>>>     --
>      >>>>>>     Petteri
>      >>>>>>
>      >>>>>>     ====== branchG: NOK
>      >>>>>>
>      >>>>>>     - no run.py file
>      >>>>>>
>      >>>>>>     ===== CoupledOscillator: NOK
>      >>>>>>
>      >>>>>>     - no run.py file
>      >>>>>>
>      >>>>>>     ===== Drosophila: OK
>      >>>>>>
>      >>>>>>     ===== Drosophila-cpp: OK
>      >>>>>>
>      >>>>>>     ===== ga: NOK
>      >>>>>>
>      >>>>>>     ecell3-session-manager ga.py
>      >>>>>>     Traceback (most recent call last):
>      >>>>>>        File "ecell3-session-manager.merge", line 116, in ?
>      >>>>>>     ImportError: No module named SessionManager
>      >>>>>>
>      >>>>>>     ===== Heatshock: NOK
>      >>>>>>
>      >>>>>>     - no run.py file
>      >>>>>>
>      >>>>>>     ===== LTD: OK
>      >>>>>>
>      >>>>>>     ===== Pendulum: NOK
>      >>>>>>
>      >>>>>>     - no run.py file
>      >>>>>>
>      >>>>>>     ===== sessionmanager: NOK
>      >>>>>>
>      >>>>>>     ecell3-session-manager ems.py
>      >>>>>>     Traceback (most recent call last):
>      >>>>>>        File \&quot;ecell3-session-manager.merge\&quot ;,
>     line 116,
>      >>>>>>     in ?
>      >>>>>>     ImportError: No module named SessionManager
>      >>>>>>
>      >>>>>>     ===== simple: NOK
>      >>>>>>
>      >>>>>>     ecell3-session run.py
>      >>>>>>     t=      0.0
>      >>>>>>     S:Value=         1000000.0
>      >>>>>>     PyECS: SIGSEGV. Invalid memory reference.
>      >>>>>>
>      >>>>>>     ===== SSystem: NOK
>      >>>>>>
>      >>>>>>     - no run.py file
>      >>>>>>
>      >>>>>>     ===== tauleap: NOK
>      >>>>>>
>      >>>>>>     - no run.py file
>      >>>>>>
>      >>>>>>     ==== Toy_Hybrid: NOK
>      >>>>>>
>      >>>>>>     - no run.py file
>      >>>>>>
>      >>>>>>
>      >>>>>>
>      >>>>>>    
>     -------------------------------------------------------------------------
> 
>      >>>>>>     Take Surveys. Earn Cash. Influence the Future of IT
>      >>>>>>     Join SourceForge.net's Techsay panel and you'll get the
>     chance
>      >>>>>>     to share your
>      >>>>>>     opinions on IT & business topics through brief surveys - and
>      >>>>>>     earn cash
>      >>>>>>    
>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>      >>>>>>    
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>>
>      >>>>>>     _______________________________________________
>      >>>>>>     Ecell-devel mailing list
>      >>>>>>     Ece...@li...
>     <mailto:Ece...@li...>
>      >>>>>>     <mailto:Ece...@li...
>     <mailto:Ece...@li...>>
>      >>>>>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
>      >>>>>>     <https://lists.sourceforge.net/lists/listinfo/ecell-devel >
>      >>>>>>
>      >>>>>>
>      >>>>>>
>      >>>>>    
>     -------------------------------------------------------------------------
>      >>>>>
>      >>>>>     Take Surveys. Earn Cash. Influence the Future of IT
>      >>>>>     Join SourceForge.net's Techsay panel and you'll get the
>     chance
>      >>>>>     to share your
>      >>>>>     opinions on IT & business topics through brief surveys - and
>      >>>>>     earn cash
>      >>>>>    
>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>      >>>>>    
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>>
>      >>>>>     _______________________________________________
>      >>>>>     Ecell-devel mailing list
>      >>>>>     Ece...@li...
>     <mailto:Ece...@li...>
>      >>>>>     <mailto:Ece...@li...
>     <mailto:Ece...@li...>>
>      >>>>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
>      >>>>    
>     -------------------------------------------------------------------------
>      >>>>     Take Surveys. Earn Cash. Influence the Future of IT
>      >>>>     Join SourceForge.net's Techsay panel and you'll get the chance
>      >>>>     to share your
>      >>>>     opinions on IT & business topics through brief surveys - and
>      >>>>     earn cash
>      >>>>    
>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>      >>>>    
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>>
>      >>>>     _______________________________________________
>      >>>>     Ecell-devel mailing list
>      >>>>     Ece...@li...
>     <mailto:Ece...@li...>
>      >>>>     <mailto: Ece...@li...
>     <mailto:Ece...@li...>>
>      >>>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
>      >>>>     < https://lists.sourceforge.net/lists/listinfo/ecell-devel>
>      >>>>
>      >>>
>      >>>    
>     -------------------------------------------------------------------------
> 
>      >>>
>      >>>     Take Surveys. Earn Cash. Influence the Future of IT
>      >>>     Join SourceForge.net's Techsay panel and you'll get the
>     chance to
>      >>>     share your
>      >>>     opinions on IT & business topics through brief surveys -
>     and earn
>      >>>     cash
>      >>>    
>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
> 
>      >>>    
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>>
>      >>>     _______________________________________________
>      >>>     Ecell-devel mailing list
>      >>>     Ece...@li...
>     <mailto:Ece...@li...>
>      >>>     <mailto: Ece...@li...
>     <mailto:Ece...@li...>>
>      >>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
>      >>
>      >>    
>     -------------------------------------------------------------------------
> 
>      >>
>      >>     Take Surveys. Earn Cash. Influence the Future of IT
>      >>     Join SourceForge.net's Techsay panel and you'll get the
>     chance to
>      >>     share your
>      >>     opinions on IT & business topics through brief surveys-and
>     earn cash
>      >>    
>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>      >>     <
>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>>
>      >>     _______________________________________________
>      >>     Ecell-devel mailing list
>      >>     Ece...@li...
>     <mailto:Ece...@li...>
>      >>     <mailto:Ece...@li...
>     <mailto:Ece...@li...>>
>      >>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
>      >
>      >     --
>      >     Petteri
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>     ------------------------------------------------------------------------
> 
>      >
>      >
>     -------------------------------------------------------------------------
>      > Take Surveys. Earn Cash. Influence the Future of IT
>      > Join SourceForge.net's Techsay panel and you'll get the chance to
>     share your
>      > opinions on IT & business topics through brief surveys-and earn cash
>      >
>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      > _______________________________________________
>      > Ecell-devel mailing list
>      > Ece...@li...
>     <mailto:Ece...@li...>
>      > https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 
>     -------------------------------------------------------------------------
> 
>     Take Surveys. Earn Cash. Influence the Future of IT
>     Join SourceForge.net's Techsay panel and you'll get the chance to
>     share your
>     opinions on IT & business topics through brief surveys-and earn cash
>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>     _______________________________________________
>     Ecell-devel mailing list
>     Ece...@li...
>     <mailto:Ece...@li...>
>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
>     <https://lists.sourceforge.net/lists/listinfo/ecell-devel>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel

Hei,

Ok. Now I see that pyunit is part of python's standard libraries since 2.1.
Therefore using it does not introduce an extra dependency in the build
platform. We can implement all the tests using it.

--
Petteri


On 3/8/07, Koichi Takahashi <sh...@sf...> wrote:
>
> Petteri,
>
> Very nice to know you are starting to work on testing suite.
>
> One important goal of such automated testing mechanism is
> to be simple and extensive.   To this end, I suggest to
> integrate everything as much as possible under pyUnit.
> This should be simple to do and will save lots of efforts
> and time.  You may need to spend an hour or two getting
> used to pyUnit but this should pay well.
>
> The kind of tests you proposed that uses sample models
> can be viewed as a kind of unit test that views ecell's
> Session mechanism as a unit.
>
> sha
>
>
>
> > Hei,
> >
> > The models in doc/sample are very suitable for "smoke testing". That is,
> > after compiling the code, you could run "make test" to verify that your
> > runtime works and to check if any basic feature is broken. Suitable
> > minimum criterium for each sample script is that it runs and exits with
> > zero if ok and  nonzero otherwise. With this kind of minimal test suite
> > in place, we can instruct users to do following when they install ecell
> > from sources.
> >
> > ./configure && make install && make test
> >
> > If anything in the environment is awfully wrong, it would surface in the
> > last "make test" phase. Which helps to pinpoint the trouble area, saves
> > everybody's time in support emails, and enables crude automatic testing.
> >
> > The next level in testing should be unit and regression testing. There
> > we could implement checking the numerical accuracy of solvers and such.
> >
> > In order to keep things simple, I would implement the "smoke test" using
> > simple makefile rules and selected models from doc/samples only. Unit
> > and regressing tests are more complex and should be made with pyunit.
> >
> > I would propose that we update the models and READMEs in doc/samples and
> > make them all uniform. If anybody could just make a sample
> > implementation with the desired calling conventions, e.g. the simple
> > model, I could start working based on that.
> >
> > --
> > Petteri
> >
> >
> >
> >>     *From: * Koichi Takahashi <sh...@sf...
> >>     <mailto:sh...@sf...>>
> >>     *Date: * March 6, 2007 9:12:40 AM JST
> >>     *To: * ka...@sf... <mailto:ka...@sf...>,
> >>     ece...@li...
> >>     <mailto:ece...@li...>
> >>     *Subject: * *Re: [Ecell-devel] doc/samples*
> >>     *Reply-To: * ece...@li...
> >>     <mailto:ece...@li...>
> >>
> >>     hi kaizu and petteri,
> >>
> >>
> >>     Recently I had a chance to look at pyUnit.   I liked it.
> >>     Perhaps you two could work together to implement make test
> >>     based on it?
> >>
> >>     sha
> >>
> >>
> >>>     Hi, Petteri!
> >>>
> >>>     I think that the samples in 'doc/sample' direcotry are for
> >>>     helping "modelers"
> >>>     to use DM classes(ex, ODE solvers) in em. They handle practical
> >>>     cases, but are
> >>>     not suited to testing. One of the reasons is that they are too
> >>>     complex to have
> >>>     an analytical solution.
> >>>     They may be appropriate for checking only whether DM classes work
> >>>     or not.
> >>>     But we need to design new test models for testing the accuracy.
> >>>
> >>>     For example, about ODE solvers, a lot of test problems have been
> >>>     proposed.
> >>>     One of the most classical sets is DETEST:
> >>>
> >>>     "Comparing Numerical Methods for Ordinary Differential Equations"
> >>>     by Hull, T.E. for non-stiff ODE
> >>>     "Comparing Numerical Methods for Stiff Systems of ODEs"
> >>>     by Enright, W.H.
> >>>
> >>>     That was designed for testing the efficiency of ODE solvers, but
> >>>     also includes
> >>>     simple problems like:
> >>>
> >>>     dy/dt = -y
> >>>     y(0)=1.0
> >>>
> >>>     -> y = y(0)*exp(-t)
> >>>
> >>>     If you need more information about it, I'll send you sample
> scripts.
> >>>     In the sample Python scritps, the results by ODE solvers are
> compared
> >>>     with the analytical solution.
> >>>
> >>>     The case for stochasitc solvers like Gillespie method are more
> >>>     complicated
> >>>     because it needs statistical analysis.
> >>>
> >>>
> >>>     I don't know much about general form of test script. Could you
> >>>     tell me the
> >>>     specifications of input and output? (Is it enough to return with
> >>>     some exception
> >>>     when the accuracy is not guaranteed?) Then, I'll modify sample
> >>>     test scripts
> >>>     to suite that.
> >>>
> >>>     Anyway, as you wrote, sample models in doc/sample directory
> >>>     should also
> >>>     include some sample scripts in it.
> >>>
> >>>     Thanks.
> >>>
> >>>
> >>>     Kaizu
> >>>
> >>>     2006/12/17, Koichi Takahashi < sh...@e-...
> >>>     <mailto:sh...@e-...>>:
> >>>>     Hei Petteri,
> >>>>
> >>>>     Great work.  Testing is important.   I appreciate it.
> >>>>
> >>>>     Two suggestions;
> >>>>
> >>>>     - Kazunari Kaizu may have made a simple test suite for ODE
> solvers
> >>>>        somewhere.  He might be able to pass it for you incorporating
> >>>>        it as part of yours.
> >>>>
> >>>>     - Satya, if some modules don't work on some platforms, these
> should
> >>>>        raise an exception when imported, not when called.   We've got
> >>>>        enough feedbacks from win users complaining they cannot run
> >>>>     Session
> >>>>        Manager.
> >>>>
> >>>>     sha
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>     Hi Petteri,
> >>>>>
> >>>>>     Thank you for your efforts. For Windows please use the newer
> >>>>>     version of
> >>>>>     E-Cell, which can be found at:
> >>>>>
> http://prdownloads.sourceforge.net/ecell/ecell-3.1.105a-gtk%2Bpython.i386.exe?download
> >>>>>     Currently, E-Cell does not support GA and SessionManager on
> Windows
> >>>>>     because we are lacking some essential Python modules for the
> >>>>>     platform.
> >>>>>
> >>>>>     satya
> >>>>>
> >>>>>
> >>>>>>     Hei,
> >>>>>>
> >>>>>>     In preparation to using `doc/samples' as test input data, I
> >>>>>>     gave them
> >>>>>>     a try on Wintel (ecell-3.1.103-gtk+python.i386.exe). Please
> >>>>>>     see below
> >>>>>>     for summary. Most of the samples don't have Python file to run
> >>>>>>     them
> >>>>>>     from command line. I could probably conjure simple ones on my
> own.
> >>>>>>     However, the authors of `ga', `sessionmanager' and `simple'
> should
> >>>>>>     have a look at those and fix them. Or admin should remove them
> >>>>>>     altogether because such broken samples do no good and can be
> >>>>>>     misleading in the worst case.
> >>>>>>
> >>>>>>     Please propose how to proceed.
> >>>>>>
> >>>>>>     --
> >>>>>>     Petteri
> >>>>>>
> >>>>>>     ====== branchG: NOK
> >>>>>>
> >>>>>>     - no run.py file
> >>>>>>
> >>>>>>     ===== CoupledOscillator: NOK
> >>>>>>
> >>>>>>     - no run.py file
> >>>>>>
> >>>>>>     ===== Drosophila: OK
> >>>>>>
> >>>>>>     ===== Drosophila-cpp: OK
> >>>>>>
> >>>>>>     ===== ga: NOK
> >>>>>>
> >>>>>>     ecell3-session-manager ga.py
> >>>>>>     Traceback (most recent call last):
> >>>>>>        File "ecell3-session-manager.merge", line 116, in ?
> >>>>>>     ImportError: No module named SessionManager
> >>>>>>
> >>>>>>     ===== Heatshock: NOK
> >>>>>>
> >>>>>>     - no run.py file
> >>>>>>
> >>>>>>     ===== LTD: OK
> >>>>>>
> >>>>>>     ===== Pendulum: NOK
> >>>>>>
> >>>>>>     - no run.py file
> >>>>>>
> >>>>>>     ===== sessionmanager: NOK
> >>>>>>
> >>>>>>     ecell3-session-manager ems.py
> >>>>>>     Traceback (most recent call last):
> >>>>>>        File \&quot;ecell3-session-manager.merge\&quot ;, line 116,
> >>>>>>     in ?
> >>>>>>     ImportError: No module named SessionManager
> >>>>>>
> >>>>>>     ===== simple: NOK
> >>>>>>
> >>>>>>     ecell3-session run.py
> >>>>>>     t=      0.0
> >>>>>>     S:Value=        1000000.0
> >>>>>>     PyECS: SIGSEGV. Invalid memory reference.
> >>>>>>
> >>>>>>     ===== SSystem: NOK
> >>>>>>
> >>>>>>     - no run.py file
> >>>>>>
> >>>>>>     ===== tauleap: NOK
> >>>>>>
> >>>>>>     - no run.py file
> >>>>>>
> >>>>>>     ==== Toy_Hybrid: NOK
> >>>>>>
> >>>>>>     - no run.py file
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> -------------------------------------------------------------------------
> >>>>>>     Take Surveys. Earn Cash. Influence the Future of IT
> >>>>>>     Join SourceForge.net's Techsay panel and you'll get the chance
> >>>>>>     to share your
> >>>>>>     opinions on IT & business topics through brief surveys - and
> >>>>>>     earn cash
> >>>>>>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >>>>>>     <
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
> >>>>>>     _______________________________________________
> >>>>>>     Ecell-devel mailing list
> >>>>>>     Ece...@li...
> >>>>>>     <mailto:Ece...@li...>
> >>>>>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
> >>>>>>     <https://lists.sourceforge.net/lists/listinfo/ecell-devel>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> -------------------------------------------------------------------------
> >>>>>
> >>>>>     Take Surveys. Earn Cash. Influence the Future of IT
> >>>>>     Join SourceForge.net's Techsay panel and you'll get the chance
> >>>>>     to share your
> >>>>>     opinions on IT & business topics through brief surveys - and
> >>>>>     earn cash
> >>>>>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >>>>>     <
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
> >>>>>     _______________________________________________
> >>>>>     Ecell-devel mailing list
> >>>>>     Ece...@li...
> >>>>>     <mailto:Ece...@li...>
> >>>>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
> >>>>
> -------------------------------------------------------------------------
> >>>>     Take Surveys. Earn Cash. Influence the Future of IT
> >>>>     Join SourceForge.net's Techsay panel and you'll get the chance
> >>>>     to share your
> >>>>     opinions on IT & business topics through brief surveys - and
> >>>>     earn cash
> >>>>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >>>>     <
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
> >>>>     _______________________________________________
> >>>>     Ecell-devel mailing list
> >>>>     Ece...@li...
> >>>>     <mailto:Ece...@li...>
> >>>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
> >>>>     <https://lists.sourceforge.net/lists/listinfo/ecell-devel>
> >>>>
> >>>
> >>>
> -------------------------------------------------------------------------
> >>>
> >>>     Take Surveys. Earn Cash. Influence the Future of IT
> >>>     Join SourceForge.net's Techsay panel and you'll get the chance to
> >>>     share your
> >>>     opinions on IT & business topics through brief surveys - and earn
> >>>     cash
> >>>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >>>     <
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
> >>>     _______________________________________________
> >>>     Ecell-devel mailing list
> >>>     Ece...@li...
> >>>     <mailto:Ece...@li...>
> >>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
> >>
> >>
> -------------------------------------------------------------------------
> >>
> >>     Take Surveys. Earn Cash. Influence the Future of IT
> >>     Join SourceForge.net's Techsay panel and you'll get the chance to
> >>     share your
> >>     opinions on IT & business topics through brief surveys-and earn
> cash
> >>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >>     <
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
> >>     _______________________________________________
> >>     Ecell-devel mailing list
> >>     Ece...@li...
> >>     <mailto:Ece...@li...>
> >>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
> >
> >     --
> >     Petteri
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys-and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Ecell-devel mailing list
> > Ece...@li...
> > https://lists.sourceforge.net/lists/listinfo/ecell-devel
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>

Petteri,

Very nice to know you are starting to work on testing suite.

One important goal of such automated testing mechanism is
to be simple and extensive.   To this end, I suggest to
integrate everything as much as possible under pyUnit.
This should be simple to do and will save lots of efforts
and time.  You may need to spend an hour or two getting
used to pyUnit but this should pay well.

The kind of tests you proposed that uses sample models
can be viewed as a kind of unit test that views ecell's
Session mechanism as a unit.

sha



> Hei,
> 
> The models in doc/sample are very suitable for "smoke testing". That is, 
> after compiling the code, you could run "make test" to verify that your 
> runtime works and to check if any basic feature is broken. Suitable 
> minimum criterium for each sample script is that it runs and exits with 
> zero if ok and  nonzero otherwise. With this kind of minimal test suite 
> in place, we can instruct users to do following when they install ecell 
> from sources.
> 
> ./configure && make install && make test
> 
> If anything in the environment is awfully wrong, it would surface in the 
> last "make test" phase. Which helps to pinpoint the trouble area, saves 
> everybody's time in support emails, and enables crude automatic testing.
> 
> The next level in testing should be unit and regression testing. There 
> we could implement checking the numerical accuracy of solvers and such.
> 
> In order to keep things simple, I would implement the "smoke test" using 
> simple makefile rules and selected models from doc/samples only. Unit 
> and regressing tests are more complex and should be made with pyunit.
> 
> I would propose that we update the models and READMEs in doc/samples and 
> make them all uniform. If anybody could just make a sample 
> implementation with the desired calling conventions, e.g. the simple 
> model, I could start working based on that.
> 
> --
> Petteri
> 
> 
> 
>>     *From: * Koichi Takahashi <sh...@sf...
>>     <mailto:sh...@sf...>>
>>     *Date: * March 6, 2007 9:12:40 AM JST
>>     *To: * ka...@sf... <mailto:ka...@sf...>,
>>     ece...@li...
>>     <mailto:ece...@li...>
>>     *Subject: * *Re: [Ecell-devel] doc/samples*
>>     *Reply-To: * ece...@li...
>>     <mailto:ece...@li...>
>>
>>     hi kaizu and petteri,
>>
>>
>>     Recently I had a chance to look at pyUnit.   I liked it.
>>     Perhaps you two could work together to implement make test
>>     based on it?
>>
>>     sha
>>
>>
>>>     Hi, Petteri!
>>>
>>>     I think that the samples in 'doc/sample' direcotry are for
>>>     helping "modelers"
>>>     to use DM classes(ex, ODE solvers) in em. They handle practical
>>>     cases, but are
>>>     not suited to testing. One of the reasons is that they are too
>>>     complex to have
>>>     an analytical solution.
>>>     They may be appropriate for checking only whether DM classes work
>>>     or not.
>>>     But we need to design new test models for testing the accuracy.
>>>
>>>     For example, about ODE solvers, a lot of test problems have been
>>>     proposed.
>>>     One of the most classical sets is DETEST:
>>>
>>>     "Comparing Numerical Methods for Ordinary Differential Equations"
>>>     by Hull, T.E. for non-stiff ODE
>>>     "Comparing Numerical Methods for Stiff Systems of ODEs"
>>>     by Enright, W.H.
>>>
>>>     That was designed for testing the efficiency of ODE solvers, but
>>>     also includes
>>>     simple problems like:
>>>
>>>     dy/dt = -y
>>>     y(0)=1.0
>>>
>>>     -> y = y(0)*exp(-t)
>>>
>>>     If you need more information about it, I'll send you sample scripts.
>>>     In the sample Python scritps, the results by ODE solvers are compared
>>>     with the analytical solution.
>>>
>>>     The case for stochasitc solvers like Gillespie method are more
>>>     complicated
>>>     because it needs statistical analysis.
>>>
>>>
>>>     I don't know much about general form of test script. Could you
>>>     tell me the
>>>     specifications of input and output? (Is it enough to return with
>>>     some exception
>>>     when the accuracy is not guaranteed?) Then, I'll modify sample
>>>     test scripts
>>>     to suite that.
>>>
>>>     Anyway, as you wrote, sample models in doc/sample directory
>>>     should also
>>>     include some sample scripts in it.
>>>
>>>     Thanks.
>>>
>>>
>>>     Kaizu
>>>
>>>     2006/12/17, Koichi Takahashi < sh...@e-...
>>>     <mailto:sh...@e-...>>:
>>>>     Hei Petteri,
>>>>
>>>>     Great work.  Testing is important.   I appreciate it.
>>>>
>>>>     Two suggestions;
>>>>
>>>>     - Kazunari Kaizu may have made a simple test suite for ODE solvers
>>>>        somewhere.  He might be able to pass it for you incorporating
>>>>        it as part of yours.
>>>>
>>>>     - Satya, if some modules don't work on some platforms, these should
>>>>        raise an exception when imported, not when called.   We've got
>>>>        enough feedbacks from win users complaining they cannot run
>>>>     Session
>>>>        Manager.
>>>>
>>>>     sha
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>     Hi Petteri,
>>>>>
>>>>>     Thank you for your efforts. For Windows please use the newer
>>>>>     version of
>>>>>     E-Cell, which can be found at:
>>>>>     http://prdownloads.sourceforge.net/ecell/ecell-3.1.105a-gtk%2Bpython.i386.exe?download
>>>>>     Currently, E-Cell does not support GA and SessionManager on Windows
>>>>>     because we are lacking some essential Python modules for the
>>>>>     platform.
>>>>>
>>>>>     satya
>>>>>
>>>>>
>>>>>>     Hei,
>>>>>>
>>>>>>     In preparation to using `doc/samples' as test input data, I
>>>>>>     gave them
>>>>>>     a try on Wintel (ecell-3.1.103-gtk+python.i386.exe). Please
>>>>>>     see below
>>>>>>     for summary. Most of the samples don't have Python file to run
>>>>>>     them
>>>>>>     from command line. I could probably conjure simple ones on my own.
>>>>>>     However, the authors of `ga', `sessionmanager' and `simple' should
>>>>>>     have a look at those and fix them. Or admin should remove them
>>>>>>     altogether because such broken samples do no good and can be
>>>>>>     misleading in the worst case.
>>>>>>
>>>>>>     Please propose how to proceed.
>>>>>>
>>>>>>     --
>>>>>>     Petteri
>>>>>>
>>>>>>     ====== branchG: NOK
>>>>>>
>>>>>>     - no run.py file
>>>>>>
>>>>>>     ===== CoupledOscillator: NOK
>>>>>>
>>>>>>     - no run.py file
>>>>>>
>>>>>>     ===== Drosophila: OK
>>>>>>
>>>>>>     ===== Drosophila-cpp: OK
>>>>>>
>>>>>>     ===== ga: NOK
>>>>>>
>>>>>>     ecell3-session-manager ga.py
>>>>>>     Traceback (most recent call last):
>>>>>>        File "ecell3-session-manager.merge", line 116, in ?
>>>>>>     ImportError: No module named SessionManager
>>>>>>
>>>>>>     ===== Heatshock: NOK
>>>>>>
>>>>>>     - no run.py file
>>>>>>
>>>>>>     ===== LTD: OK
>>>>>>
>>>>>>     ===== Pendulum: NOK
>>>>>>
>>>>>>     - no run.py file
>>>>>>
>>>>>>     ===== sessionmanager: NOK
>>>>>>
>>>>>>     ecell3-session-manager ems.py
>>>>>>     Traceback (most recent call last):
>>>>>>        File \&quot;ecell3-session-manager.merge\&quot ;, line 116,
>>>>>>     in ?
>>>>>>     ImportError: No module named SessionManager
>>>>>>
>>>>>>     ===== simple: NOK
>>>>>>
>>>>>>     ecell3-session run.py
>>>>>>     t=      0.0
>>>>>>     S:Value=        1000000.0
>>>>>>     PyECS: SIGSEGV. Invalid memory reference.
>>>>>>
>>>>>>     ===== SSystem: NOK
>>>>>>
>>>>>>     - no run.py file
>>>>>>
>>>>>>     ===== tauleap: NOK
>>>>>>
>>>>>>     - no run.py file
>>>>>>
>>>>>>     ==== Toy_Hybrid: NOK
>>>>>>
>>>>>>     - no run.py file
>>>>>>
>>>>>>
>>>>>>
>>>>>>     -------------------------------------------------------------------------
>>>>>>     Take Surveys. Earn Cash. Influence the Future of IT
>>>>>>     Join SourceForge.net's Techsay panel and you'll get the chance
>>>>>>     to share your
>>>>>>     opinions on IT & business topics through brief surveys - and
>>>>>>     earn cash
>>>>>>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>>>>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>>>>>>     _______________________________________________
>>>>>>     Ecell-devel mailing list
>>>>>>     Ece...@li...
>>>>>>     <mailto:Ece...@li...>
>>>>>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
>>>>>>     <https://lists.sourceforge.net/lists/listinfo/ecell-devel>
>>>>>>
>>>>>>
>>>>>>
>>>>>     -------------------------------------------------------------------------
>>>>>
>>>>>     Take Surveys. Earn Cash. Influence the Future of IT
>>>>>     Join SourceForge.net's Techsay panel and you'll get the chance
>>>>>     to share your
>>>>>     opinions on IT & business topics through brief surveys - and
>>>>>     earn cash
>>>>>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>>>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>>>>>     _______________________________________________
>>>>>     Ecell-devel mailing list
>>>>>     Ece...@li...
>>>>>     <mailto:Ece...@li...>
>>>>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
>>>>     -------------------------------------------------------------------------
>>>>     Take Surveys. Earn Cash. Influence the Future of IT
>>>>     Join SourceForge.net's Techsay panel and you'll get the chance
>>>>     to share your
>>>>     opinions on IT & business topics through brief surveys - and
>>>>     earn cash
>>>>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>>>>     _______________________________________________
>>>>     Ecell-devel mailing list
>>>>     Ece...@li...
>>>>     <mailto:Ece...@li...>
>>>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
>>>>     <https://lists.sourceforge.net/lists/listinfo/ecell-devel>
>>>>
>>>
>>>     -------------------------------------------------------------------------
>>>
>>>     Take Surveys. Earn Cash. Influence the Future of IT
>>>     Join SourceForge.net's Techsay panel and you'll get the chance to
>>>     share your
>>>     opinions on IT & business topics through brief surveys - and earn
>>>     cash
>>>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>>>     _______________________________________________
>>>     Ecell-devel mailing list
>>>     Ece...@li...
>>>     <mailto:Ece...@li...>
>>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
>>
>>     -------------------------------------------------------------------------
>>
>>     Take Surveys. Earn Cash. Influence the Future of IT
>>     Join SourceForge.net's Techsay panel and you'll get the chance to
>>     share your
>>     opinions on IT & business topics through brief surveys-and earn cash
>>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>>     _______________________________________________
>>     Ecell-devel mailing list
>>     Ece...@li...
>>     <mailto:Ece...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/ecell-devel
> 
>     --
>     Petteri
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel

Hei,

The models in doc/sample are very suitable for "smoke testing". That is,
after compiling the code, you could run "make test" to verify that your
runtime works and to check if any basic feature is broken. Suitable minimum
criterium for each sample script is that it runs and exits with zero if ok
and  nonzero otherwise. With this kind of minimal test suite in place, we
can instruct users to do following when they install ecell from sources.

./configure && make install && make test

If anything in the environment is awfully wrong, it would surface in the
last "make test" phase. Which helps to pinpoint the trouble area, saves
everybody's time in support emails, and enables crude automatic testing.

The next level in testing should be unit and regression testing. There we
could implement checking the numerical accuracy of solvers and such.

In order to keep things simple, I would implement the "smoke test" using
simple makefile rules and selected models from doc/samples only. Unit and
regressing tests are more complex and should be made with pyunit.

I would propose that we update the models and READMEs in doc/samples and
make them all uniform. If anybody could just make a sample implementation
with the desired calling conventions, e.g. the simple model, I could start
working based on that.

--
Petteri



*From: *Koichi Takahashi <sh...@sf...>
> *Date: *March 6, 2007 9:12:40 AM JST
> *To: *ka...@sf..., ece...@li...
> *Subject: **Re: [Ecell-devel] doc/samples*
> *Reply-To: *ece...@li...
>
> hi kaizu and petteri,
>
>
> Recently I had a chance to look at pyUnit.  I liked it.
> Perhaps you two could work together to implement make test
> based on it?
>
> sha
>
>
> Hi, Petteri!
>
> I think that the samples in 'doc/sample' direcotry are for helping
> "modelers"
> to use DM classes(ex, ODE solvers) in em. They handle practical cases, but
> are
> not suited to testing. One of the reasons is that they are too complex to
> have
> an analytical solution.
> They may be appropriate for checking only whether DM classes work or not.
> But we need to design new test models for testing the accuracy.
>
> For example, about ODE solvers, a lot of test problems have been proposed.
> One of the most classical sets is DETEST:
>
> "Comparing Numerical Methods for Ordinary Differential Equations"
> by Hull, T.E. for non-stiff ODE
> "Comparing Numerical Methods for Stiff Systems of ODEs"
> by Enright, W.H.
>
> That was designed for testing the efficiency of ODE solvers, but also
> includes
> simple problems like:
>
> dy/dt = -y
> y(0)=1.0
>
> -> y = y(0)*exp(-t)
>
> If you need more information about it, I'll send you sample scripts.
> In the sample Python scritps, the results by ODE solvers are compared
> with the analytical solution.
>
> The case for stochasitc solvers like Gillespie method are more complicated
> because it needs statistical analysis.
>
>
> I don't know much about general form of test script. Could you tell me the
> specifications of input and output? (Is it enough to return with some
> exception
> when the accuracy is not guaranteed?) Then, I'll modify sample test
> scripts
> to suite that.
>
> Anyway, as you wrote, sample models in doc/sample directory should also
> include some sample scripts in it.
>
> Thanks.
>
>
> Kaizu
>
> 2006/12/17, Koichi Takahashi <sh...@e-...>:
>
> Hei Petteri,
>
> Great work.  Testing is important.  I appreciate it.
>
> Two suggestions;
>
> - Kazunari Kaizu may have made a simple test suite for ODE solvers
>    somewhere.  He might be able to pass it for you incorporating
>    it as part of yours.
>
> - Satya, if some modules don't work on some platforms, these should
>    raise an exception when imported, not when called.   We've got
>    enough feedbacks from win users complaining they cannot run Session
>    Manager.
>
> sha
>
>
>
>
>
> Hi Petteri,
>
> Thank you for your efforts. For Windows please use the newer version of
> E-Cell, which can be found at:
>
> http://prdownloads.sourceforge.net/ecell/ecell-3.1.105a-gtk%2Bpython.i386.exe?download
> Currently, E-Cell does not support GA and SessionManager on Windows
> because we are lacking some essential Python modules for the platform.
>
> satya
>
>
> Hei,
>
> In preparation to using `doc/samples' as test input data, I gave them
> a try on Wintel (ecell-3.1.103-gtk+python.i386.exe). Please see below
> for summary. Most of the samples don't have Python file to run them
> from command line. I could probably conjure simple ones on my own.
> However, the authors of `ga', `sessionmanager' and `simple' should
> have a look at those and fix them. Or admin should remove them
> altogether because such broken samples do no good and can be
> misleading in the worst case.
>
> Please propose how to proceed.
>
> --
> Petteri
>
> ====== branchG: NOK
>
> - no run.py file
>
> ===== CoupledOscillator: NOK
>
> - no run.py file
>
> ===== Drosophila: OK
>
> ===== Drosophila-cpp: OK
>
> ===== ga: NOK
>
> ecell3-session-manager ga.py
> Traceback (most recent call last):
>    File "ecell3-session-manager.merge", line 116, in ?
> ImportError: No module named SessionManager
>
> ===== Heatshock: NOK
>
> - no run.py file
>
> ===== LTD: OK
>
> ===== Pendulum: NOK
>
> - no run.py file
>
> ===== sessionmanager: NOK
>
> ecell3-session-manager ems.py
> Traceback (most recent call last):
>    File \&quot;ecell3-session-manager.merge\&quot;, line 116, in ?
> ImportError: No module named SessionManager
>
> ===== simple: NOK
>
> ecell3-session run.py
> t=      0.0
> S:Value=        1000000.0
> PyECS: SIGSEGV. Invalid memory reference.
>
> ===== SSystem: NOK
>
> - no run.py file
>
> ===== tauleap: NOK
>
> - no run.py file
>
> ==== Toy_Hybrid: NOK
>
> - no run.py file
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>
>
> --
> Petteri
>
>
>
>
>

hi kaizu and petteri,


Recently I had a chance to look at pyUnit.  I liked it.
Perhaps you two could work together to implement make test
based on it?

sha


> Hi, Petteri!
> 
> I think that the samples in 'doc/sample' direcotry are for helping "modelers"
> to use DM classes(ex, ODE solvers) in em. They handle practical cases, but are
> not suited to testing. One of the reasons is that they are too complex to have
> an analytical solution.
> They may be appropriate for checking only whether DM classes work or not.
> But we need to design new test models for testing the accuracy.
> 
> For example, about ODE solvers, a lot of test problems have been proposed.
> One of the most classical sets is DETEST:
> 
> "Comparing Numerical Methods for Ordinary Differential Equations"
> by Hull, T.E. for non-stiff ODE
> "Comparing Numerical Methods for Stiff Systems of ODEs"
> by Enright, W.H.
> 
> That was designed for testing the efficiency of ODE solvers, but also includes
> simple problems like:
> 
> dy/dt = -y
> y(0)=1.0
> 
> -> y = y(0)*exp(-t)
> 
> If you need more information about it, I'll send you sample scripts.
> In the sample Python scritps, the results by ODE solvers are compared
> with the analytical solution.
> 
> The case for stochasitc solvers like Gillespie method are more complicated
> because it needs statistical analysis.
> 
> 
> I don't know much about general form of test script. Could you tell me the
> specifications of input and output? (Is it enough to return with some exception
> when the accuracy is not guaranteed?) Then, I'll modify sample test scripts
> to suite that.
> 
> Anyway, as you wrote, sample models in doc/sample directory should also
> include some sample scripts in it.
> 
> Thanks.
> 
> 
> Kaizu
> 
> 2006/12/17, Koichi Takahashi <sh...@e-...>:
>> Hei Petteri,
>>
>> Great work.  Testing is important.  I appreciate it.
>>
>> Two suggestions;
>>
>> - Kazunari Kaizu may have made a simple test suite for ODE solvers
>>    somewhere.  He might be able to pass it for you incorporating
>>    it as part of yours.
>>
>> - Satya, if some modules don't work on some platforms, these should
>>    raise an exception when imported, not when called.   We've got
>>    enough feedbacks from win users complaining they cannot run Session
>>    Manager.
>>
>> sha
>>
>>
>>
>>
>>
>>> Hi Petteri,
>>>
>>> Thank you for your efforts. For Windows please use the newer version of
>>> E-Cell, which can be found at:
>>> http://prdownloads.sourceforge.net/ecell/ecell-3.1.105a-gtk%2Bpython.i386.exe?download
>>> Currently, E-Cell does not support GA and SessionManager on Windows
>>> because we are lacking some essential Python modules for the platform.
>>>
>>> satya
>>>
>>>
>>>> Hei,
>>>>
>>>> In preparation to using `doc/samples' as test input data, I gave them
>>>> a try on Wintel (ecell-3.1.103-gtk+python.i386.exe). Please see below
>>>> for summary. Most of the samples don't have Python file to run them
>>>> from command line. I could probably conjure simple ones on my own.
>>>> However, the authors of `ga', `sessionmanager' and `simple' should
>>>> have a look at those and fix them. Or admin should remove them
>>>> altogether because such broken samples do no good and can be
>>>> misleading in the worst case.
>>>>
>>>> Please propose how to proceed.
>>>>
>>>> --
>>>> Petteri
>>>>
>>>> ====== branchG: NOK
>>>>
>>>> - no run.py file
>>>>
>>>> ===== CoupledOscillator: NOK
>>>>
>>>> - no run.py file
>>>>
>>>> ===== Drosophila: OK
>>>>
>>>> ===== Drosophila-cpp: OK
>>>>
>>>> ===== ga: NOK
>>>>
>>>> ecell3-session-manager ga.py
>>>> Traceback (most recent call last):
>>>>    File "ecell3-session-manager.merge", line 116, in ?
>>>> ImportError: No module named SessionManager
>>>>
>>>> ===== Heatshock: NOK
>>>>
>>>> - no run.py file
>>>>
>>>> ===== LTD: OK
>>>>
>>>> ===== Pendulum: NOK
>>>>
>>>> - no run.py file
>>>>
>>>> ===== sessionmanager: NOK
>>>>
>>>> ecell3-session-manager ems.py
>>>> Traceback (most recent call last):
>>>>    File \&quot;ecell3-session-manager.merge\&quot;, line 116, in ?
>>>> ImportError: No module named SessionManager
>>>>
>>>> ===== simple: NOK
>>>>
>>>> ecell3-session run.py
>>>> t=      0.0
>>>> S:Value=        1000000.0
>>>> PyECS: SIGSEGV. Invalid memory reference.
>>>>
>>>> ===== SSystem: NOK
>>>>
>>>> - no run.py file
>>>>
>>>> ===== tauleap: NOK
>>>>
>>>> - no run.py file
>>>>
>>>> ==== Toy_Hybrid: NOK
>>>>
>>>> - no run.py file
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> Take Surveys. Earn Cash. Influence the Future of IT
>>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>>> opinions on IT & business topics through brief surveys - and earn cash
>>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>> _______________________________________________
>>>> Ecell-devel mailing list
>>>> Ece...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>>>>
>>>>
>>>>
>>> -------------------------------------------------------------------------
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>> opinions on IT & business topics through brief surveys - and earn cash
>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> Ecell-devel mailing list
>>> Ece...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Ecell-devel mailing list
>> Ece...@li...
>> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>>
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ecell-devel mailing list
> Ece...@li...
> https://lists.sourceforge.net/lists/listinfo/ecell-devel