From: Kent B. <kg...@la...> - 2010-10-21 20:37:27
|
On Thu, 2010-10-21 at 16:02 -0400, Aaron Dotter wrote: > > But I can't seem to build 2734 correctly under gfortran 4.5.0. > It > compiles, but there are subtle differences in the eos tests > and more > serious differences in the model tests. Any ideas? > > > Can you provide some more system details, like OS? uname -a yields Linux gondolin.lanl.gov 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux > > > In general, we do expect some minor differences in the test results > when compiled on different machines or different compilers than the > one where the standard results were produced, especially if OpenMP is > involved. What do you mean by more serious differences? > The eos test problem differences do look like roundoff. The star test problem differences involve actual crashing of code. I found one of the problems already: The test_star_inlist file appears to be missing the line / ! end of controls namelist at the obvious location for it, as downloaded by subversion. I've added the line and the problem now runs to completion. Don't know if it's your repository that is missing the line or whether subversion experienced a hickup. My sense is that it is something like a distributed CVS so the latter seems unlikely, but I am new to this environment. > > Also, we do have some reports that gfortran 4.5.0 is problematic. On > the Mac, 4.5.1 should work. On linux, I'm pretty sure that 4.4.4 > works but I have no information about 4.5.*. If you have access to > ifort, you are encouraged to use it as it (at least version 11) has no > known problems with the current MESA. We are only to version 1.10 on ifort so I should probably hold off on that until we update. Will soldier on with gfortran 4.5.0 unless I hit a brick wall; I can then drop back to 4.4.4 if necessary. However, I may try building with the PGI F95 compiler, which is fairly widely used hereabouts, just to see what happens. > > > Thanks for being patient with the tyro. I am eager to > contribute to the > project, particularly in testing out some new turbulent mixing > models > and in possibly providing C/C++ wrappers for some of the > modules and a > Tcl/Tk interface to the 1-D star code. Apologies if someone is > already > working on these or if I have just stepped in the middle of a > computer > language holy war. > > > No language evangelism here so far. The MESA Council is happy to look > at anything that can broaden or improve the experience. All of the > things you mentioned sound great! > > > Aaron Excellent. I've been talking with Chris Fryer about getting funding to compare some different turbulent mixing models; he's the one who pointed me at MESA. I've been playing with my own C++ evolution code, which has been great fun, but it seems unwise to reinvent so many wheels. (Though my code does have an explicit hydrodynamics option that may be worth preserving. Then again, perhaps not in 1-D.) I'm going to take a stab at C/C++ wrappers for some of the modules then, with an eye towards including some conditionally compiled Design By Contract checks. Will do this without touching the underlying MESA F95 modules as far as possible. Then I can try wiring this up with Tcl/Tk. How does a window with a running plot of the H-R track as you calculate it grab you? Am anxious to learn proper project etiquette as well. What is the process for submitting new code or code changes? -- Kent G. Budge |