[mpas-developers] alternate mesh decomposition file names

[Michael Duda]

Hi, All.

I'd like to propose a set of changes to the trunk that would allow
us to specify the prefix for mesh decomposition files, as Todd
suggested below. In the attached changes, I've used a new namelist
variable config_decomp_file_prefix in the &io record, though I'm
open to better suggestions. Also included in the attached tar file
are changes to the top-level Makefile to use big-endian format for
unformatted reads and writes, which we'll be using for lookup
tables in atmospheric physics and for initial atmospheric fields
for real-data simulations.

If there are any questions or comments, please don't hesitate to
let me know!

Cheers,
Michael


On Wed, Oct 27, 2010 at 01:12:20PM -0600, Todd Ringler wrote:
> 
> ...
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Thanks again for putting together a reorg of the init procedure.
> 
> Cheers,
> Todd
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: changes_20101129.tar.gz
Type: application/octet-stream
Size: 6722 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/mpas-developers/attachments/20101129/3de1a2bf/attachment.obj