<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Hi Michael, <div><br></div><div>Thanks for pushing on this. It is definitely an aspect of the model that needs a bit of work. In addition to my comments below, I think that Mark Petersen will be scoping the potential advantages/disadvantages of the proposed changes.</div><div><br></div><div>I think that it is entirely reasonable to assume that some form of output will be generated. If possible, it might be a good idea to make an runtime check to see if this is actually the case given the namelist file so that we can exit gracefully if needed.</div><div><br></div><div>On another note (that is related to this topic because it is done at init) is the issue of graph.info.part.* . If have two recommendations that we can consider to be a part of this reorganization or addressed separately.</div><div><br></div><div>The first is that we might want to be able to specify the "graph.info.part" part of the input file through the namelist. We are generating a lot of meshes and the graph files go with the meshes. Metis names the graph files to be analogous to the grid files and this makes sense. As a result, I do a lot of copying like "cp x1.2562.graph.info.part.8 graph.info.part.8" into my run directory. A generalization would make the graph input similar the grid input, i.e. we can specify the form of both. The difference here is that we would require a way to get the number of tasks at runtime (before opening the graph file) in order to complete the graph file name.</div><div><br></div><div>The second graph issue is that we should be able to run the model with "mpirun -np 1 ocean.exe" with no graph file present. I have verified that the model runs in this mode by creating my own graph.info.part.1 files (kmetis will not produce these!). This configuration essentially turns off the MPI and provides a means of testing certain aspects of the model. I guess that this would be pretty trivial if, again, we could we can retrieve the number of processors before opening the graph file.</div><div><br></div><div>This might be more of a "graph" issue than an "init" issue and we might be better off pushing this to a later reorganization. I just wanted to bring it up now in case you think that it is easy to address at present.</div><div><br></div><div>Thanks again for putting together a reorg of the init procedure.</div><div><br></div><div>Cheers,</div><div>Todd</div><div><br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><span style="font-family: Helvetica; font-size: medium; color: rgb(0, 0, 0); "><b>From: </b></span><span style="font-family: Helvetica; font-size: medium; ">"Todd D. Ringler" <<a href="mailto:ringler@lanl.gov">ringler@lanl.gov</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><span style="font-family: Helvetica; font-size: medium; color: rgb(0, 0, 0); "><b>Date: </b></span><span style="font-family: Helvetica; font-size: medium; ">October 27, 2010 11:06:37 AM MDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><span style="font-family: Helvetica; font-size: medium; color: rgb(0, 0, 0); "><b>To: </b></span><span style="font-family: Helvetica; font-size: medium; "><a href="mailto:todd.ringler@mac.com">todd.ringler@mac.com</a><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><span style="font-family: Helvetica; font-size: medium; color: rgb(0, 0, 0); "><b>Subject: </b></span><span style="font-family: Helvetica; font-size: medium; "><b>[Fwd: [mpas-developers] Restructuring high-level MPAS driver]</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><span style="font-family: Helvetica; font-size: medium; color: rgb(0, 0, 0); "><b>Reply-To: </b></span><span style="font-family: Helvetica; font-size: medium; "><a href="mailto:ringler@lanl.gov">ringler@lanl.gov</a><br></span></div><br><div>---------------------------- Original Message ----------------------------<br>Subject: [mpas-developers] Restructuring high-level MPAS driver<br>From: "Michael Duda" <<a href="mailto:duda@ucar.edu">duda@ucar.edu</a>><br>Date: Tue, October 26, 2010 4:30 pm<br>To: <a href="mailto:mpas-developers@ucar.edu">mpas-developers@ucar.edu</a><br>--------------------------------------------------------------------------<br><br>Hi, Developers.<br><br>I've been working to restructure the higher levels of the MPAS software<br>(driver and subdriver) to enable us to separate the test case<br>initialization from the model proper, among other things, and I've<br>settled on what I think is a set of changes that will take us in the<br>proper direction.<br><br>Currently, in the current top-level code (mpas.F and module_subdriver.F),<br>the setup_test_cases() routine is called directly, which precludes the<br>separation of this from the model. I view the initialization code that<br>is currently in module_test_cases.F as something of its own "core" that<br>uses the MPAS software infrastructure in the same way that the sw,<br>nhyd_atmos, and ocean cores use this infrastructure. Consequently, I'd<br>like to generalize both mpas.F and module_subdriver.F by removing any<br>core-specific code, where the definition of "core" now includes<br>initialization, post-processing, etc. Under this generalization, the<br>content of mpas.F would be a main program that simply calls init(),<br>run(), and finalize() routines in the subdriver module, and the<br>subdriver module's init() implementation would be responsible for<br>initializing the framework (infrastructure) and then the core; to<br>further abstract the details of the infrastructure and core, I'm also<br>proposing that we provide main modules for each of these, which would<br>implement their own init, run, and finalize routines. Calls to<br>setup_test_cases() could still exist within either the init() or run()<br>routines implemented by the core's main module, if at all; however,<br>with a separated initialization, the initialization would exist as<br>its own core, whose run() routine would perform the work currently<br>done in setup_test_cases().<br><br>I've placed a tar file to illustrate what these changes look like<br>in <a href="http://www.mmm.ucar.edu/people/duda/files/mpas/mpas_newdriver.tar.gz">http://www.mmm.ucar.edu/people/duda/files/mpas/mpas_newdriver.tar.gz</a>.<br>This code is an svn working copy, so it should be possible to 'svn<br>status' and 'svn diff' to see what files have changed. During the<br>restructuring, I found that the mpas_query() routine is no longer<br>needed, since number of time levels can be determined for fields purely<br>in the registry, so I also removed code related to this, too.<br><br>One side effect in the currently reorganization is that both the output<br>and restart files are always opened at the start of MPAS execution,<br>regardless of whether a core intends to write a restart file at all.<br>This raises the question of whether control over output (and perhpas<br>even input) streams should be given to the individual MPAS cores. Would<br>assuming that a core always writes at least an output stream, but may<br>not write a restart stream be reasonable for now? If so, we could<br>probably relocate code to open/write/close the restart file down to the<br>core-specific code, for example.<br><br>On the upside, the restructuring that I've proposed has very little<br>impact on the actual solver code in the MPAS cores; and, I've found<br>that the high-level code is lightweight enough that it should be easy<br>to make further changes as we move forward with future development.<br><br>I apologize for the lengthy e-mail, but if anyone has any comments,<br>particularly concerning other requirements besides separating<br>initialization from model integration, I'd be very glad to hear them.<br>Assuming no objections that cannot be remedied, I'd like to commit<br>the proposed changes to the repository trunk fairly soon.<br><br>Cheers,<br>Michael<br>_______________________________________________<br>mpas-developers mailing list<br><a href="mailto:mpas-developers@mailman.ucar.edu">mpas-developers@mailman.ucar.edu</a><br><a href="http://mailman.ucar.edu/mailman/listinfo/mpas-developers">http://mailman.ucar.edu/mailman/listinfo/mpas-developers</a><br><br></div></blockquote></div></div></div></body></html>