From: Upinder S. B. <bh...@nc...> - 2007-02-02 03:09:15
|
Dear all, I have added Niraj Dudani to the developers list for MOOSE. Niraj has been working primarily on the MOOSE hsolver, but has also done the Windows compilation and now has the additional entertaining job of putting the new version of MOOSE onto SourceForge so that we all can play with it. More generally, I expect that he will implement the site updates that have been pending for a long while, such as making the documentation more visible, providing precompiled versions and so on. Cheers, Upi --=20 Upinder S. Bhalla National Centre for Biological Sciences, bh...@nc... Tata Institute of Fundamental Research, +91-80-23666130 Bellary Road, Fax: +91-80-23636662 Bangalore 560065, INDIA Web: http://www.ncbs.res.in/~bhalla/index.html |
From: Niraj D. <ni...@nc...> - 2007-02-05 18:33:02
|
Hi all, The new and improved MOOSE has been checked in. Upi has put MOOSE through a weight loss programme, and it shows--do refer to the commit log for further info. Invite your comments. Cheers, Niraj |
From: Hugo C. <hug...@gm...> - 2007-02-05 21:18:59
|
I took a look at this new release, and it looks almost like a reimplementation from scratch. I only had a superficial glance, but I like the overall code and it gives a more consistent and transparant impression than the previous release. I have several questions: 1. I don't see any of the biophysics / parallel / solver stuff anymore. So, or this is work in progress, or this has been accidently forgotten/removed. It would be nice to know what the status is, and to have at least two or three examples of how to work with the new basecode. 2. I would like to learn more about the relationships between Finfo and Ftype and related. e.g. why do we need Ftype and Ftype2. Is there any more documentation available about the general relationships ? 3. a question about the tests: wouldn't it be better to separate the code from the tests completely from the code from the core ? I have seen to many cases where bugs in test code were interfering with bugs in the tested code, such that everything seemed to work properly although it was not. For instance, the SimpleElement seems to be intended for tests only, but is shipped in the basecode directory. 4. If I am correct, Element specific data is supposed to be hidden with the ->data() method. I am not sure if I like this idea or not, it has both advantages and disadvantages: to make sure that I understand: my guess is that it avoids cases of multiple inheritance, and it decouples privately owned data, so might require more implementation work and cause run-time overhead. I think of this as a major design decision, and it is different from the previous release of Moose. Can you explain the rationale for this, can you explain why the previous release of Moose did this differently and what the problems were ? 5. Is it correct to say that this version of Moose adds array based fields and that this was not present in the previous release ? Is this a preparation for array based messaging ? Hugo On 2/5/07, Niraj Dudani <ni...@nc...> wrote: > > Hi all, > > The new and improved MOOSE has been checked in. Upi has put MOOSE through > a weight loss programme, and it shows--do refer to the commit log for > further info. > > Invite your comments. > > Cheers, > Niraj > > > > > ------------------------------------------------------------------------- > 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...> - 2007-02-06 02:59:54
|
Dear all, As Niraj's checkin message stated, we have started a complete reimplementation based on lessons from the MOOSE2006 API. There are many more details in the subversion log in the intro section, and there is als= o a documentation directory that has a couple of sections handwritten, and becomes richly populated when you run doxygen. Hugo has brought up most of the key additional points: > > 1. I don't see any of the biophysics / parallel / solver stuff > anymore. So, or this is work in progress, or this has been accidently forgotten/removed. It would be nice to know what the status is, and to have at least two or three examples of how to work with the new basecode. Yes, these are works in progress. I thought we should go for the 'release early, release often' policy. You will see a lot more activity on the subversion tree as a result. Immediate development sequence: - flesh out the parser interfaces. Currently compiles with Python/SWIG, but I'll use the same function hooks to talk to the old GENESIS parser. - Bring over the scheduling structure from MOOSE06 - Set up biophysics - Set up hsolver (Niraj is working on this) Examples of how to work with the new base code will be in the form of the biophysics modules. In principle I could do those right away, but without the scheduling and parser stuff that would not be terribly functional. Bu= t you can look at the element/Neutral files to get a preview. > > 2. I would like to learn more about the relationships between Finfo and Ftype and related. e.g. why do we need Ftype and Ftype2. Is there any more documentation available about the general relationships ? Finfos hold information about fields. They are not typed, and rely on the templated Ftype classes to handle type specific functions and information= . This separation helps because it keeps templating to a minimum and encourages most operations to remain generic. > > 3. a question about the tests: wouldn't it be better to separate the code from the tests completely from the code from the core ? I have seen to many cases where bugs in test code were interfering with bugs in the tested code, such that everything seemed to work properly although it was not. For instance, the SimpleElement seems to be intended for tests only, but is shipped in the basecode directory. The tests are all wrapped in #ifdef DO_UNIT_TESTS. I like to have them close to the classes they test because then it is easier to understand what they are doing. I have assertions everywhere, and those are intentional. Again, asserts can be flagged out of the system when we are sure it works well. SimpleElement is actually used for everything. It is currently the only instantiable version of Element. > > 4. If I am correct, Element specific data is supposed to be hidden with the ->data() method. I am not sure if I like this idea or not, it has both advantages and disadvantages: to make sure that I > understand: my guess is that it avoids cases of multiple inheritance, and it decouples privately owned data, so might require more > implementation work and cause run-time overhead. I think of this as a major design decision, and it is different from the previous release of Moose. Can you explain the rationale for this, can you explain why the previous release of Moose did this differently and what the > problems were ? Well, you've pointed out both the pros and the cons. It avoids multiple inheritance and decouples private data at the cost of an extra indirection. Another big reason for doing this is that it makes it easier to set up variants of the Element class. As it turns out, it has helped a lot in keeping the implementation of the wrapper code separate from the user object code. For example, message and field handling becomes much more modular in this system than it was earlier. > > 5. Is it correct to say that this version of Moose adds array based fields and that this was not present in the previous release ? Is this a preparation for array based messaging ? > Array fields are now cleaner, but I did have a clunkier version previously. I'm not sure what you mean by array-based messaging. We can now send and receive messages from individual array entries. We were always able to send and receive entire arrays. Cheers, Upi |