Menu
▾
▴
moose-devel — Development issues
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(8) |
Jul
(3) |
Aug
(27) |
Sep
(10) |
Oct
(1) |
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(8) |
| 2013 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
|
| 2014 |
Jan
|
Feb
(1) |
Mar
(13) |
Apr
(41) |
May
(20) |
Jun
(5) |
Jul
(5) |
Aug
|
Sep
(3) |
Oct
(4) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Upinder S. B. <bh...@nc...> - 2006-08-29 05:26:40
|
Dear Greg et al, Thanks for raising some very important and interesting points. I have not yet thought much about parallel model loading, because I don't have much idea about how much of a bottleneck it might be. Before I dive into the details, this is my earlier line of thought; please comment on it. 1. Threads: I had considered restricting multithreading to solvers, on a per-node basis, for some of the reasons Greg has outlined. 2. RelativeFind etc: I had considered caching info on the postmaster to speed up the process of finding remote objects, and grouping requests for remote-node element info. 3. Parallel model building: I thought that almost all cases where this would be critical would be through special calls like createmap, region-connect, and perhaps copy. Most of these can be rather cleanly don= e in parallel with minimal internode communication. However, a global checkpoint would be needed to ensure synchrony between these calls. I should also add that the divide between setup time and runtime is probably not so clean and we will definitely need to figure out efficient ways of handling this. For example, in signalling simulations I have already had issues where new organelles are budding off and being destroyed at runtime. To consider Greg's points: > The greatest concern I have is with the many places in the basecode tha= t make an implicit assumption that elements are locally resident in the nodes's memory, and that only one thread will be actively > modifying them. (...) > Some form of locking will thus be needed (probably on a per-Element bas= is). Couldn't we put a lock at an appropriate place in an element tree, but permit other element trees to be accessed safely ? >The most troublesome situations will be when > modifications are being made to the element tree, such as when new >elements are being created or old ones destroyed. Can we have a lock set whenever 'dangerous' commands are being executed? Most commands at runtime are relatively safe. > One solution may be to standardize at the .mh level.... This approach > might make sense if nearly all the > visualization and other add-on code would be at the .mh level or higher= , > but not if those things require major changes to the existing basecode. I'm not sure what you have in mind here. To me it looks like all the locking stuff should be done at the basecode level, so the user does not need to know about it even if they are developing new objects using .mh files. Could you expand on it? -- Upi |
|
From: Michael E. <mie...@gm...> - 2006-08-29 02:15:21
|
Hardware is also moving in an increasingly thread optimized direction, so making moose thread friendly will go a long way to making it run well on future machines. On 8/28/06, Greg Hood <gh...@ps...> wrote: > Upi, > I have been looking at the MOOSE code, and thinking about certain issues > involved in parallelizing it, and have some serious concerns. > > The greatest concern I have is with the many places in the basecode > that make an implicit assumption that elements are locally resident in > the nodes's memory, and that only one thread will be actively > modifying them. For example, if the elements are distributed over > many nodes, then Element::relativeFind() will potentially require > information on 2 or more nodes. This will cause the code to block for > indefinite periods of time while the interprocess communication is > performed and the remote nodes do what they need to do. The simplest > way of dealing with this would be to only allow one active thread over > the entire set of nodes on which MOOSE is running. However, this > would be disastrous in term of performance -- network setup would be > much slower than doing it on a single node. If we allow multiple > active threads on each node to avoid the performance hit, then every > method that directly or indirectly calls one of these methods that > require off-node information will potentially block. While this > occurs, incoming requests from other nodes must be handled, and some > of those may involve the Element in question. Some form of locking will > thus be needed (probably on a per-Element basis). The difficult thing > is that each of the places in the code where a potentially blocking > call will occur will have to release the Element lock, and must leave > the Element (as well as any kernel data structures) in a safe and > consistent state. I can't see this being done without rewriting many > sections of code. The most troublesome situations will be when > modifications are being made to the element tree, such as when new > elements are being created or old ones destroyed. Once the network is > set up, things may not be so bad, but the network needs to get set up > in order to run it. > > One solution may be to standardize at the .mh level. The existing > MOOSE code could support running models (i.e., a script + a set of .mh > files) on serial machines, and we could have a separately developed > parallel version that can run the same models. A few changes would > probably still be needed to the existing .mh files, but probably not > too many. This approach might make sense if nearly all the visualization > and other add-on code would be at the .mh level or higher, but not if > those things require major changes to the existing basecode. > > If you have thought of solutions to any of these problems, I would > be interested in hearing about them. > --Greg > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Moose-g3-devel mailing list > Moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > |
|
From: Greg H. <gh...@ps...> - 2006-08-28 23:17:00
|
Upi, I have been looking at the MOOSE code, and thinking about certain issues involved in parallelizing it, and have some serious concerns. The greatest concern I have is with the many places in the basecode that make an implicit assumption that elements are locally resident in the nodes's memory, and that only one thread will be actively modifying them. For example, if the elements are distributed over many nodes, then Element::relativeFind() will potentially require information on 2 or more nodes. This will cause the code to block for indefinite periods of time while the interprocess communication is performed and the remote nodes do what they need to do. The simplest way of dealing with this would be to only allow one active thread over the entire set of nodes on which MOOSE is running. However, this would be disastrous in term of performance -- network setup would be much slower than doing it on a single node. If we allow multiple active threads on each node to avoid the performance hit, then every method that directly or indirectly calls one of these methods that require off-node information will potentially block. While this occurs, incoming requests from other nodes must be handled, and some of those may involve the Element in question. Some form of locking will thus be needed (probably on a per-Element basis). The difficult thing is that each of the places in the code where a potentially blocking call will occur will have to release the Element lock, and must leave the Element (as well as any kernel data structures) in a safe and consistent state. I can't see this being done without rewriting many sections of code. The most troublesome situations will be when modifications are being made to the element tree, such as when new elements are being created or old ones destroyed. Once the network is set up, things may not be so bad, but the network needs to get set up in order to run it. One solution may be to standardize at the .mh level. The existing MOOSE code could support running models (i.e., a script + a set of .mh files) on serial machines, and we could have a separately developed parallel version that can run the same models. A few changes would probably still be needed to the existing .mh files, but probably not too many. This approach might make sense if nearly all the visualization and other add-on code would be at the .mh level or higher, but not if those things require major changes to the existing basecode. If you have thought of solutions to any of these problems, I would be interested in hearing about them. --Greg |
|
From: Josef S. <js...@ya...> - 2006-08-23 19:50:17
|
Agreed, but also to avoid possible confusion with lower-level libraries. If we were doing system-level work (up through code development tools, maybe), we might use a single or even double leading underscore. --- "Upinder S. Bhalla" <bh...@nc...> wrote: > Dear Hugo, > > I'm following > > http://geosoft.no/development/cppstyle.html > > See item 11. > > -- Upi > > > > On Wed, August 23, 2006 8:04 pm, Hugo Cornelis said: > > I thought that private variable are normally _prefixed_ with an > > underscore ? Is there a specific reason to deviate from the common > > convention ? > > > > > > Hugo > > > > > > On 8/22/06, Upinder S. Bhalla <bh...@nc...> wrote: > >> Hi, Greg, > >> Yes, this is a bit confusing. I haven't really prioritized it, but it > >> should be possible to massage the preprocessor to deal with these > >> cases. The reasoning goes like this: All private variables have an > >> appended underscore. Public field names (which may be associated with a > >> private variable) do not. However, in the preprocessor .mh file we > >> sometimes need to define operations on private variables. At this point > >> the preprocessor just lets those lines through into the generated > >> files, so we end up using a mix of Vm and Vm_ variable names. It is > >> easy to keep track of if you remember when you are writing a function > >> that talks to the private fields. > >> > >> Hope this helps, > >> Upi > >> > >> -- > >> Upinder S. Bhalla National Centre for Biological Sciences, > >> bh...@nc... Tata Institute of Fundamental Research, > >> +91-80-2363-6420X3230 Bellary Road, > >> Fax: +91-80-23636662 Bangalore 560065, INDIA > >> Web: http://www.ncbs.res.in/~bhalla/index.html > >> > >> On Wed, August 23, 2006 4:37 am, Greg Hood said: > >> > Upi, > >> > In the Moose developers guide the MyClass example has several > >> variables > >> > with an underscore appended (e.g., Vm_), but these are not declared > >> > anywhere > >> > that I can see. I see similar occurrences in the CaConc.mh and > >> > Compartment.mh files. Are these variables somehow automatically > >> declared? > >> > In Compartment.mh, some of these (A_, B_) are declared in the > >> "private:" > >> > section, but others (Im_, Ra_) are not, so this is very confusing. > >> > --Greg > >> > > >> > > ------------------------------------------------------------------------- > >> > Using Tomcat but need to do more? Need to support web services, > >> security? > >> > Get stuff done quickly with pre-integrated technology to make your job > >> > easier > >> > Download IBM WebSphere Application Server v.1.0.1 based on Apache > >> Geronimo > >> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > >> > _______________________________________________ > >> > Moose-g3-devel mailing list > >> > Moo...@li... > >> > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > >> > > >> > >> > >> > >> ------------------------------------------------------------------------- > >> Using Tomcat but need to do more? Need to support web services, > >> security? > >> Get stuff done quickly with pre-integrated technology to make your job > >> easier > >> Download IBM WebSphere Application Server v.1.0.1 based on Apache > >> Geronimo > >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > >> _______________________________________________ > >> Moose-g3-devel mailing list > >> Moo...@li... > >> https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > >> > > > > > > -- > > Hugo Cornelis Ph.D. > > > > Research Imaging Center > > University of Texas Health Science Center at San Antonio > > 7703 Floyd Curl Drive > > San Antonio, TX 78284-6240 > > > > Phone: 210 567 8112 > > Fax: 210 567 8152 > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Moose-g3-devel mailing list > > Moo...@li... > > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Moose-g3-devel mailing list > Moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > js...@ya... Software Engineer Linux/OSX C/C++/Java |
|
From: Upinder S. B. <bh...@nc...> - 2006-08-23 15:19:11
|
Dear Hugo, I'm following http://geosoft.no/development/cppstyle.html See item 11. -- Upi On Wed, August 23, 2006 8:04 pm, Hugo Cornelis said: > I thought that private variable are normally _prefixed_ with an > underscore ? Is there a specific reason to deviate from the common > convention ? > > > Hugo > > > On 8/22/06, Upinder S. Bhalla <bh...@nc...> wrote: >> Hi, Greg, >> Yes, this is a bit confusing. I haven't really prioritized it, but = it >> should be possible to massage the preprocessor to deal with these >> cases. The reasoning goes like this: All private variables have an >> appended underscore. Public field names (which may be associated with = a >> private variable) do not. However, in the preprocessor .mh file we >> sometimes need to define operations on private variables. At this poin= t >> the preprocessor just lets those lines through into the generated >> files, so we end up using a mix of Vm and Vm_ variable names. It is >> easy to keep track of if you remember when you are writing a function >> that talks to the private fields. >> >> Hope this helps, >> Upi >> >> -- >> Upinder S. Bhalla National Centre for Biological Sciences, >> bh...@nc... Tata Institute of Fundamental Research, >> +91-80-2363-6420X3230 Bellary Road, >> Fax: +91-80-23636662 Bangalore 560065, INDIA >> Web: http://www.ncbs.res.in/~bhalla/index.html >> >> On Wed, August 23, 2006 4:37 am, Greg Hood said: >> > Upi, >> > In the Moose developers guide the MyClass example has several >> variables >> > with an underscore appended (e.g., Vm_), but these are not declared >> > anywhere >> > that I can see. I see similar occurrences in the CaConc.mh and >> > Compartment.mh files. Are these variables somehow automatically >> declared? >> > In Compartment.mh, some of these (A_, B_) are declared in the >> "private:" >> > section, but others (Im_, Ra_) are not, so this is very confusing. >> > --Greg >> > >> > --------------------------------------------------------------------= ----- >> > Using Tomcat but need to do more? Need to support web services, >> security? >> > Get stuff done quickly with pre-integrated technology to make your j= ob >> > easier >> > Download IBM WebSphere Application Server v.1.0.1 based on Apache >> Geronimo >> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&= dat=3D121642 >> > _______________________________________________ >> > Moose-g3-devel mailing list >> > Moo...@li... >> > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel >> > >> >> >> >> ----------------------------------------------------------------------= --- >> Using Tomcat but need to do more? Need to support web services, >> security? >> Get stuff done quickly with pre-integrated technology to make your job >> easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache >> Geronimo >> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&da= t=3D121642 >> _______________________________________________ >> Moose-g3-devel mailing list >> Moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moose-g3-devel >> > > > -- > Hugo Cornelis Ph.D. > > Research Imaging Center > University of Texas Health Science Center at San Antonio > 7703 Floyd Curl Drive > San Antonio, TX 78284-6240 > > Phone: 210 567 8112 > Fax: 210 567 8152 > > -----------------------------------------------------------------------= -- > Using Tomcat but need to do more? Need to support web services, securit= y? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron= imo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Moose-g3-devel mailing list > Moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > |
|
From: Hugo C. <hug...@gm...> - 2006-08-23 14:41:50
|
I thought that private variable are normally _prefixed_ with an underscore ? Is there a specific reason to deviate from the common convention ? Hugo On 8/22/06, Upinder S. Bhalla <bh...@nc...> wrote: > Hi, Greg, > Yes, this is a bit confusing. I haven't really prioritized it, but it > should be possible to massage the preprocessor to deal with these > cases. The reasoning goes like this: All private variables have an > appended underscore. Public field names (which may be associated with a > private variable) do not. However, in the preprocessor .mh file we > sometimes need to define operations on private variables. At this point > the preprocessor just lets those lines through into the generated > files, so we end up using a mix of Vm and Vm_ variable names. It is > easy to keep track of if you remember when you are writing a function > that talks to the private fields. > > Hope this helps, > Upi > > -- > Upinder S. Bhalla National Centre for Biological Sciences, > bh...@nc... Tata Institute of Fundamental Research, > +91-80-2363-6420X3230 Bellary Road, > Fax: +91-80-23636662 Bangalore 560065, INDIA > Web: http://www.ncbs.res.in/~bhalla/index.html > > On Wed, August 23, 2006 4:37 am, Greg Hood said: > > Upi, > > In the Moose developers guide the MyClass example has several variables > > with an underscore appended (e.g., Vm_), but these are not declared > > anywhere > > that I can see. I see similar occurrences in the CaConc.mh and > > Compartment.mh files. Are these variables somehow automatically declared? > > In Compartment.mh, some of these (A_, B_) are declared in the "private:" > > section, but others (Im_, Ra_) are not, so this is very confusing. > > --Greg > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Moose-g3-devel mailing list > > Moo...@li... > > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Moose-g3-devel mailing list > Moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > -- Hugo Cornelis Ph.D. Research Imaging Center University of Texas Health Science Center at San Antonio 7703 Floyd Curl Drive San Antonio, TX 78284-6240 Phone: 210 567 8112 Fax: 210 567 8152 |
|
From: Upinder S. B. <bh...@nc...> - 2006-08-23 02:51:20
|
Hi, Greg, Yes, this is a bit confusing. I haven't really prioritized it, but it should be possible to massage the preprocessor to deal with these cases. The reasoning goes like this: All private variables have an appended underscore. Public field names (which may be associated with a private variable) do not. However, in the preprocessor .mh file we sometimes need to define operations on private variables. At this point the preprocessor just lets those lines through into the generated files, so we end up using a mix of Vm and Vm_ variable names. It is easy to keep track of if you remember when you are writing a function that talks to the private fields. Hope this helps, Upi --=20 Upinder S. Bhalla National Centre for Biological Sciences, bh...@nc... Tata Institute of Fundamental Research, +91-80-2363-6420X3230 Bellary Road, Fax: +91-80-23636662 Bangalore 560065, INDIA Web: http://www.ncbs.res.in/~bhalla/index.html On Wed, August 23, 2006 4:37 am, Greg Hood said: > Upi, > In the Moose developers guide the MyClass example has several variables > with an underscore appended (e.g., Vm_), but these are not declared > anywhere > that I can see. I see similar occurrences in the CaConc.mh and > Compartment.mh files. Are these variables somehow automatically declar= ed? > In Compartment.mh, some of these (A_, B_) are declared in the "private:= " > section, but others (Im_, Ra_) are not, so this is very confusing. > --Greg > > -----------------------------------------------------------------------= -- > Using Tomcat but need to do more? Need to support web services, securit= y? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron= imo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Moose-g3-devel mailing list > Moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > |
|
From: Greg H. <gh...@ps...> - 2006-08-22 23:07:33
|
Upi, In the Moose developers guide the MyClass example has several variables with an underscore appended (e.g., Vm_), but these are not declared anywhere that I can see. I see similar occurrences in the CaConc.mh and Compartment.mh files. Are these variables somehow automatically declared? In Compartment.mh, some of these (A_, B_) are declared in the "private:" section, but others (Im_, Ra_) are not, so this is very confusing. --Greg |
|
From: Michael E. <mie...@gm...> - 2006-08-19 01:39:07
|
Hugo and I had discussed the autoconf and automake scripts as a good place for Mando to start working with the Moose code, since we thought they should be done sooner and later, and also because we didn't figure anyone else wanted to. On 8/17/06, Josef Svitak <js...@ya...> wrote: > > --- Greg Hood <gh...@ps...> wrote: > > > > I agree that configure is badly needed. I am familiar with autoconf and > > have written configure scripts before, so I might be able to contribute > > to this. Had anyone else already planned on writing a configure script > > for MOOSE? As far as Windows goes, I would favor a development environment > > that is based on the Cygwin tools (which will give us autoconf, make, etc.). > > with the understanding that the final executable should not require the > > user to have Cygwin installed. > > --Greg > > In theory (meaning I've never tried it), you don't have to install Cygwin to > use the autoconf tools. See > http://gnuwin32.sourceforge.net/packages/autoconf.htm It just needs perl and > msvcrt.dll (MS Visual C++ runtime library - think you'd be hard-pressed to find > a windows system without this installed!). Autoconf on *nix generates _shell_ > scripts. If windows needs a shell to run, you might be able to use > http://win-bash.sourceforge.net/ > > (in response to Upi's off-list comments, but applicable here) > IMHO, it's NEVER too early to start using this kind of tool. The time it will > save every developer will quickly dwarf any time spent ramping up. > > joe > > > js...@ya... > Software Engineer > Linux/OSX C/C++/Java > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Moose-g3-devel mailing list > Moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > |
|
From: Josef S. <js...@ya...> - 2006-08-18 03:51:52
|
The sourceforge mailing list archives appear to be working again. I didn't notice any missing posts. js...@ya... Software Engineer Linux/OSX C/C++/Java |
|
From: Josef S. <js...@ya...> - 2006-08-18 03:49:22
|
The problems with compiling using gcc 4.1 vs 4.0 stem from stricter adherence to the C99 Ansi Standard. Code which slipped by under '-pedantic' in earlier versions will no longer compile on 4.1 and later. However, code which compiles cleanly on 4.1 should compile cleanly in earlier versions. There doesn't seem to be any set of flags that allows this code to compile, so the short term fix is to use an older version of the compiler. The longer term fix is to fix the sticky spots in the code. I'll fork a topic on that... On Wed, August 15, 2006 4:45 pm, Upinder S. Bhalla said: > I am using g++ (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) on > Linux version 2.6.15-26-686. > I checked against the version in the SourceForge repository. It is the > same. So it seems to be a compiler issue. > I guess I need to set up a preliminary compile set on a group of lab > machines. I'll see if anyone in the lab has FC5 running. > I have flex 2.5.31 On Tue, August 15, 2006 1:36 am, Josef Svitak said: > Moose will not compile on g++-4.1 on FC5. Not sure how far-reaching this > problem is. Compiling with g++32 (compatibility version 3.2) gets farther > along > but dies on the --c++ flag to flex++ (version 2.5.4). > > joe js...@ya... Software Engineer Linux/OSX C/C++/Java |
|
From: Josef S. <js...@ya...> - 2006-08-17 06:00:54
|
--- Greg Hood <gh...@ps...> wrote: > > I agree that configure is badly needed. I am familiar with autoconf and > have written configure scripts before, so I might be able to contribute > to this. Had anyone else already planned on writing a configure script > for MOOSE? As far as Windows goes, I would favor a development environment > that is based on the Cygwin tools (which will give us autoconf, make, etc.). > with the understanding that the final executable should not require the > user to have Cygwin installed. > --Greg In theory (meaning I've never tried it), you don't have to install Cygwin to use the autoconf tools. See http://gnuwin32.sourceforge.net/packages/autoconf.htm It just needs perl and msvcrt.dll (MS Visual C++ runtime library - think you'd be hard-pressed to find a windows system without this installed!). Autoconf on *nix generates _shell_ scripts. If windows needs a shell to run, you might be able to use http://win-bash.sourceforge.net/ (in response to Upi's off-list comments, but applicable here) IMHO, it's NEVER too early to start using this kind of tool. The time it will save every developer will quickly dwarf any time spent ramping up. joe js...@ya... Software Engineer Linux/OSX C/C++/Java |
|
From: Greg H. <gh...@ps...> - 2006-08-17 04:45:16
|
Josef Svitak writes: > --- Hugo Cornelis wrote: > > In a more general context, a couple of other things we need are : > > > > - configure as a unifying deployment interface to other developments, > > e.g. such that Genesis3 can be a subproject of another project or > > vice-versa. > > - again configure, such that we can deal with most of the portability > > issues for C/C++. > > This is debatably the most critical piece missing from Moose at the moment. The > Autoconf family of tools is still the best choice for *nixes, including OSX. > For Windows, I think the jury is out. We may be able to start with autoconf, > but CMake or SCons are more like choices. I agree that configure is badly needed. I am familiar with autoconf and have written configure scripts before, so I might be able to contribute to this. Had anyone else already planned on writing a configure script for MOOSE? As far as Windows goes, I would favor a development environment that is based on the Cygwin tools (which will give us autoconf, make, etc.). with the understanding that the final executable should not require the user to have Cygwin installed. --Greg |
|
From: Josef S. <js...@ya...> - 2006-08-17 01:38:15
|
Embedded comments. > On 8/16/06, Josef Svitak wrote: > > The Moose architecture needs some major overhaul before it will be ready > for > > prime time. This means that anybody doing development on/against it will > > probably be facing some fairly major refactoring in the future. Hopefully, > the > > kind of major source code manipulation which Hugo employed with Genesis > will > > not be needed with Moose. Hugo, if you find yourself maintaining your own > > version control trees, please let someone know so we can find a way to > > incorporate the needed functionality. > > My understanding was that you would compile and run a simulation, then checkout a different version of the source code, compile and run, ...ad nauseum. That's the situation I hope is avoidable in G3. --- Hugo Cornelis wrote: > Here is the view I take for developing Genesis3 code : It is common > for a developer to maintain his own code base, at the same time it > must be possible to synchronize between different code bases, and > especially to push important changes to the main line of development. > These are all important aspects of software development that we must > _encourage_ : put people in control over the things they need. > > What is needed for Genesis3 is distributed version control, such that > different people can work on different lines of development, e.g. I > can work on my code, while Upi is working on his code, and other > developers -- e.g. students or supporters -- are working on their > copies, without disrupting main line developments. I am in the phase > of evaluating Monotone (http://www.venge.net/monotone/), has excellent > design, good performance, integrated branch-merging, several GUIs and > an active community. I don't really see any benefits to using monotone over subversion or even cvs. The only problem with modern version control systems in general is developers checking in code which breaks the compile. We could set up subversion so that approval is required for checkins and I think we may even be able to run a compile. At a minimum, we could encourage developers to run 'svn update' and 'make' by displaying a message before the commit. See the 'Hook Scripts' section of http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html for more information. > > In a more general context, a couple of other things we need are : > > - configure as a unifying deployment interface to other developments, > e.g. such that Genesis3 can be a subproject of another project or > vice-versa. > - again configure, such that we can deal with most of the portability > issues for C/C++. This is debatably the most critical piece missing from Moose at the moment. The Autoconf family of tools is still the best choice for *nixes, including OSX. For Windows, I think the jury is out. We may be able to start with autoconf, but CMake or SCons are more like choices. > - automated testing, including coverage analysis, we should not rely > on sourceforge for this. agreed. sf doesn't have any special tools to aid in this endeavor anyway, other than the ability to compile on a range of platforms which we probably don't have access to. > - community tools (a wiki, bugtracker, etc.). Such tools and their > performance are going to be the major contributors to the success of > Genesis3. I know Michael already took a look at some candidates. I've been trying to stress how important these kind of tools will be. Please carry the banner for me, Hugo! js...@ya... Software Engineer Linux/OSX C/C++/Java |
|
From: Upinder S. B. <bh...@nc...> - 2006-08-15 16:45:29
|
Hi, Joe, I am using g++ (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) on Linux version 2.6.15-26-686. I checked against the version in the SourceForge repository. It is the same. So it seems to be a compiler issue. I guess I need to set up a preliminary compile set on a group of lab machines. I'll see if anyone in the lab has FC5 running. I have flex 2.5.31 BTW, great work on the look of the site and logo. -- Upi On Tue, August 15, 2006 1:36 am, Josef Svitak said: > Moose will not compile on g++-4.1 on FC5. Not sure how far-reaching thi= s > problem is. Compiling with g++32 (compatibility version 3.2) gets farth= er > along > but dies on the --c++ flag to flex++ (version 2.5.4). > > joe > > js...@ya... > Software Engineer > Linux/OSX C/C++/Java > > -----------------------------------------------------------------------= -- > Using Tomcat but need to do more? Need to support web services, securit= y? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron= imo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Moose-g3-devel mailing list > Moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > |
|
From: Josef S. <js...@ya...> - 2006-08-14 20:06:33
|
Moose will not compile on g++-4.1 on FC5. Not sure how far-reaching this problem is. Compiling with g++32 (compatibility version 3.2) gets farther along but dies on the --c++ flag to flex++ (version 2.5.4). joe js...@ya... Software Engineer Linux/OSX C/C++/Java |
|
From: Josef S. <js...@ya...> - 2006-08-04 17:08:55
|
Yes, the archiving is supposed to be automatic AND immediate. The mailing list appears to have stopped archiving around July 24. There are several support requests open on this issue which I'm monitoring. I'm examining the possibility of mirroring mailing list posts to a forum. joe --- Dave Beeman <db...@do...> wrote: > Joe, > > When I look at Email Archive: moose-g3-devel via the > sf.net/projects/moose-g3 page, the latest posting it shows is the > 2006-06-16 one by you on topographica. None of the recent exchanges > with Greg and Upi appear, nor my 26 Jul 2006 post on the March 2006 GENESIS > development Workshop Summary. Is the archiving supposed to be automatic? > > Dave > > js...@ya... Software Engineer Linux/OSX C/C++/Java |
|
From: Upinder S. B. <bh...@nc...> - 2006-08-04 02:54:17
|
Dear Kay, I completely agree about variables. For backward compatibility reasons we have taken the old GENESIS parser in all its glory into the current MOOSE, but the intention is to eventually deprecate it and use SWIG. SWIG allows one to wrap any of about 20 scripting languages and with it the simulator can talk to a more modern language such as Python. If someone is fond of messing with flex and bison it might be possible to make local variables within the current parser framework, but I don't see that as a high priority. -- Upi On Fri, August 4, 2006 2:41 am, Kay Robbins said: > Dave Beeman reminded me to post this for the record... > > As development of Genesis scripting goes forward, it is important > to have a designator for constants that are local to a file. > Otherwise the definitions of contants depend on the order of the > include files. By having local constants, you can have the > definition of a particular neuron in a file with the parameters > specified as constants at the top. Global constants are a source > of a LOT of insidious errors. > > Thanks, > Kay > > > > Moose-g3-devel mailing list > Moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > |
|
From: Kay R. <kro...@cs...> - 2006-08-03 21:11:24
|
Dave Beeman reminded me to post this for the record... As development of Genesis scripting goes forward, it is important to have a designator for constants that are local to a file. Otherwise the definitions of contants depend on the order of the include files. By having local constants, you can have the definition of a particular neuron in a file with the parameters specified as constants at the top. Global constants are a source of a LOT of insidious errors. Thanks, Kay |
|
From: Josef S. <js...@ya...> - 2006-08-03 14:44:50
|
--- "Upinder S. Bhalla" <bh...@nc...> wrote: > Greg Hood said: > > 3. mpp preprocessor > > If someone has an X.mh file and runs it through the mpp preprocessor, > then > > they get X.h, XWrapper.h, and XWrapper.cpp files out. Under what > circumstances > > does one need to hand modify these files? I would argue that this > should > > never be happen. Here's a thought: why not have a single X.moose file > that > > contains all information about the MOOSE classes, and let mpp translate > this > > into read-only X.h, X.cpp, XWrapper.h, and XWrapper.cpp files, possibly > locating these in a C++/ subdirectory so they will not clutter up the > developer's working directory. The MOOSE developer should not have to > directly deal with these .h and .cpp files anyway. By judicious use of > #line directives in the .h and .cpp files, any errors in the C++ > compilations can be referred back to the original X.moose file. > > This is almost exactly what I would like and am working toward. At this > point the preprocessor is incomplete, partly because the base code still > has some way to go. But you'll find that revision 5 is _much_ improved and > can do about 95% of the job of generating X.h, XWrapper.h and XWrapper.cpp > files without user intervention. More like 100% in the case of > straightforward classes, which are what most users would need. > One difference is that the X.cpp file is intentionally not supported. The > idea is that this is stuff that the user will want to code independently > of the wrapper stuff. For example, if there were serious calculations > needed inside an object, we don't want to squash it all into the X.mh file > (think of the X.mh file as a super 'header' file). These would then go > into X.cpp. The X.cpp functions need not know about MOOSE at all. > BTW, I am not keen to use #lines. Phenomenally ugly! I agree that these are ugly, but you can take some license with generated code since the hope is that ultimately noone should ever have to look at it. js...@ya... Software Engineer Linux/OSX C/C++/Java |
|
From: Upinder S. B. <bh...@nc...> - 2006-08-03 03:23:12
|
Hi, Greg, Thanks for the feedback. I hope you have had a chance to look at revision 5 or later from the SVN repository. Here are my responses. Greg Hood said: > > 1. pointers versus handles > The typical way that an element is referenced within MOOSE is by a pointer > (Element *). What this effectively means is that objects are frozen to a particular memory location on a particular node, and it will be next to > impossible to later move them to different nodes. Is that limitation acceptable to you? The alternative would be to use some sort of handle that is a persistent identifier of that object, regardless of its location. As you say, pointer reference is not a good idea, and is meant to be encapsulated in messages. Note that the object hierarchy (/root/foo/bar) is maintained through 'child' messages. These messages are the correct handle to use. I currently permit pointer reference for atomic operations like tree searches. The idea is that these operations should be local and should be instantaneous, ie, no other operation should mess with the tree structure while they occur. Messages as handles are quite general and can stretch across nodes, much like the older GENESIS messages. As it turns out, the solver design which I'm working on also is purely message based. In principle one could have solved objects on multiple nodes. Why anyone would want to do this is another matter! > > 2. ReturnFinfo > I'm not exactly sure what sort of thing ReturnFinfo is supposed to be used > for. (I couldn't find an instance of its use in the examples.) My interpretation of its function is that it immediately returns a value fro= m the receiving element to the sending element. This will cause trouble if the sending element is on a different node than the receiving element, because the sender will have to be delayed while MPI messages are sent an= d received. This means that the sender will need its own thread, unless al= l computation is to be blocked while waiting for MPI (a very bad thing). I= f the sender is in its own thread, then much locking > will be needed to ensure that other threads on that node do not stomp o= n each other. > Yes, ReturnFinfo is meant to return a value immediately. Example is table lookup in channel calculations. Multiple differnt channel instances will want to look up the same alpha/beta table, and will each have their own values to find. Yes, it is bad to run this across nodes. The system should object if this is attempted. As you can see from the example above, the purpose of this message is to avoid the use of pointers but still permit shared resources. If you want to do this across nodes you can duplicate the target. I haven't yet froze= n the semantics, but as presently used, ReturnFinfo is readonly. > 3. mpp preprocessor > If someone has an X.mh file and runs it through the mpp preprocessor, then > they get X.h, XWrapper.h, and XWrapper.cpp files out. Under what circumstances > does one need to hand modify these files? I would argue that this should > never be happen. Here's a thought: why not have a single X.moose file that > contains all information about the MOOSE classes, and let mpp translate this > into read-only X.h, X.cpp, XWrapper.h, and XWrapper.cpp files, possibly locating these in a C++/ subdirectory so they will not clutter up the developer's working directory. The MOOSE developer should not have to directly deal with these .h and .cpp files anyway. By judicious use of #line directives in the .h and .cpp files, any errors in the C++ compilations can be referred back to the original X.moose file. This is almost exactly what I would like and am working toward. At this point the preprocessor is incomplete, partly because the base code still has some way to go. But you'll find that revision 5 is _much_ improved an= d can do about 95% of the job of generating X.h, XWrapper.h and XWrapper.cp= p files without user intervention. More like 100% in the case of straightforward classes, which are what most users would need. One difference is that the X.cpp file is intentionally not supported. The idea is that this is stuff that the user will want to code independently of the wrapper stuff. For example, if there were serious calculations needed inside an object, we don't want to squash it all into the X.mh fil= e (think of the X.mh file as a super 'header' file). These would then go into X.cpp. The X.cpp functions need not know about MOOSE at all. BTW, I am not keen to use #lines. Phenomenally ugly! > > 4. semantics of "messages" needs to be clearer > I have read various documents under DOCS/ that describe messages, but I'm > still fuzzy on exactly how they work, and why all the different types o= f messages are needed. It would be good to have some concrete examples to refer to, in order to make this clearer. For example, I'm not clear how the clocks for the source and destination elements affect transmission of > information across messages (if at all). Also, I'd still like to push to change the name of a "message" to something else (connection? link?), since "message" in CS terminology has a connotation of a one-shot delivery > of information. Similarly, to conform to general usage, "object" shoul= d replace "element", and "class" should replace "object". > Two points here: Message functionality and the name message. Message functionality: Think of them as remote function calls with persistent traversal information. Remote in this context means to another object, wherever it lives. I have a list somewhere in the documentation o= f all the message categories, 7 at last count. Yes, this is a big number an= d could probably be tightened. I want to first get all the base code stuff done (solvers and parallelization in particular still remain) before assessing how the different varieties of message behave and seeing if the= y can be condensed without loss of efficiency. The name 'message': this is a hangover from GENESIS. I actually use the term connection for the underlying traversal framework, and 'message' for the overall construct. I don't see how we can easily rename it without breaking backward compatibility assumptions, but I am quite open to suggestions. As I recall we have had this discussion before, inconclusively. > 5. Why are synapses treated separately in the Moose header files? Since synapses are just messages, why should they be given a separate section within a Moose class definition? This is just because they are a special kind of message. Synapses associate extra information with each message (weight, delay, etc) which is allocated on a per-message basis and is not part of the argument list. > > 6. How would variable-timestep methods be handled? > The clock-based scheduling appears very similar to that found in GENESI= S Solvers handle variable-timestep stuff. When a solver is set up, it inserts itself into the scheduling object hierarchy, and replaces the usual clocktick object that calls the equivalent of the PROCESS action. Then it is up to the solver to decide how to interface with the schedulin= g calls. Individual variable-timestep solvers are no problem in this context. They get the universal clock ticks from the scheduler and make sure that they are within the appropriate time window. I've already done something like this in GENESIS 2 for the Gillespie solver. Multiple variable-timestep solvers may need to negotiate if they depend o= n mutual data. 2. > How do you envision an element that is capable of variable-timestep updating being handled? See above. > > I don't know if you prefer to discuss these issues in e-mail, or want t= o try to do a teleconference (possibly with VNC???) with those of us intere= sted > in this level of detail. Let me know what works best for you. I think these are very good questions to bring up, and they should be on record at the MOOSE site to help developers as they dig in. Thanks, Upi |
|
From: Greg H. <gh...@ps...> - 2006-08-02 21:03:44
|
Upi, I have spent the past week looking through the MOOSE code and documentation, and am trying to get a good understanding of it before deciding on the best way of parallelizing it. I don't feel that I have yet reached that point, but in the meantime I have several concerns that I'd like to discuss with you: 1. pointers versus handles The typical way that an element is referenced within MOOSE is by a pointer (Element *). What this effectively means is that objects are frozen to a particular memory location on a particular node, and it will be next to impossible to later move them to different nodes. Is that limitation acceptable to you? The alternative would be to use some sort of handle that is a persistent identifier of that object, regardless of its location. 2. ReturnFinfo I'm not exactly sure what sort of thing ReturnFinfo is supposed to be used for. (I couldn't find an instance of its use in the examples.) My interpretation of its function is that it immediately returns a value from the receiving element to the sending element. This will cause trouble if the sending element is on a different node than the receiving element, because the sender will have to be delayed while MPI messages are sent and received. This means that the sender will need its own thread, unless all computation is to be blocked while waiting for MPI (a very bad thing). If the sender is in its own thread, then much locking will be needed to ensure that other threads on that node do not stomp on each other. 3. mpp preprocessor If someone has an X.mh file and runs it through the mpp preprocessor, then they get X.h, XWrapper.h, and XWrapper.cpp files out. Under what circumstances does one need to hand modify these files? I would argue that this should never be happen. Here's a thought: why not have a single X.moose file that contains all information about the MOOSE classes, and let mpp translate this into read-only X.h, X.cpp, XWrapper.h, and XWrapper.cpp files, possibly locating these in a C++/ subdirectory so they will not clutter up the developer's working directory. The MOOSE developer should not have to directly deal with these .h and .cpp files anyway. By judicious use of #line directives in the .h and .cpp files, any errors in the C++ compilations can be referred back to the original X.moose file. 4. semantics of "messages" needs to be clearer I have read various documents under DOCS/ that describe messages, but I'm still fuzzy on exactly how they work, and why all the different types of messages are needed. It would be good to have some concrete examples to refer to, in order to make this clearer. For example, I'm not clear how the clocks for the source and destination elements affect transmission of information across messages (if at all). Also, I'd still like to push to change the name of a "message" to something else (connection? link?), since "message" in CS terminology has a connotation of a one-shot delivery of information. Similarly, to conform to general usage, "object" should replace "element", and "class" should replace "object". 5. Why are synapses treated separately in the Moose header files? Since synapses are just messages, why should they be given a separate section within a Moose class definition? 6. How would variable-timestep methods be handled? The clock-based scheduling appears very similar to that found in GENESIS 2. How do you envision an element that is capable of variable-timestep updating being handled? I don't know if you prefer to discuss these issues in e-mail, or want to try to do a teleconference (possibly with VNC???) with those of us interested in this level of detail. Let me know what works best for you. Thanks. --Greg |
|
From: Hugo C. <hug...@gm...> - 2006-08-02 15:55:44
|
Some feedback from an artistic pro (has worked in Holywood). In the logo, the G is carrying to much weight, can perhaps be corrected by underlying the fully logo with an orange line, to support the G carrying the M and 3. For the rest, the logo looks great. Can the authors table be put in the same style as the news table ? The orange gives an overall warm and cosy impression. Looks good. Hugo On 7/26/06, Josef Svitak <js...@ya...> wrote: > Hi All, > > Any feedback on the Alpha-stage moose website would be greatly appreciated. > > http://moose-g3.sourceforge.net > > If it seems like more than a couple of people want to collaborate on the actual > website, we can put the whole thing under wiki control so it could be mostly > editable from any web browser. > > joe > > js...@ya... > Software Engineer > Linux/OSX C/C++/Java > > ------------------------------------------------------------------------- > 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 > _______________________________________________ > Moose-g3-devel mailing list > Moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > -- Hugo Cornelis Ph.D. Research Imaging Center University of Texas Health Science Center at San Antonio 7703 Floyd Curl Drive San Antonio, TX 78284-6240 Phone: 210 567 8112 Fax: 210 567 8152 |
|
From: Michael E. <mie...@gm...> - 2006-07-29 15:32:21
|
The logo looks a bit like "moose-a3" rather than "g3". Other than that it looks fine. On 7/26/06, Josef Svitak <js...@ya...> wrote: > Hi All, > > Any feedback on the Alpha-stage moose website would be greatly appreciated. > > http://moose-g3.sourceforge.net > > If it seems like more than a couple of people want to collaborate on the actual > website, we can put the whole thing under wiki control so it could be mostly > editable from any web browser. > > joe > > js...@ya... > Software Engineer > Linux/OSX C/C++/Java > > ------------------------------------------------------------------------- > 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 > _______________________________________________ > Moose-g3-devel mailing list > Moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-g3-devel > |
|
From: Josef S. <js...@ya...> - 2006-07-28 22:08:55
|
Hi All, Any feedback on the Alpha-stage moose website would be greatly appreciated. http://moose-g3.sourceforge.net If it seems like more than a couple of people want to collaborate on the actual website, we can put the whole thing under wiki control so it could be mostly editable from any web browser. joe js...@ya... Software Engineer Linux/OSX C/C++/Java |
3 messages has been excluded from this view by a project administrator.
