[mpas-developers] alternate mesh decomposition file names

Michael Duda duda at ucar.edu
Tue Dec 28 11:34:50 MST 2010


Hi, All.                                                                                                                                              
                                                                                                                                                      
Just a bit of advance notice regarding the proposed changes below                                                                                     
(user-specifiable mesh partition file name and big-endian compiler                                                                                    
options): I'll plan to commit these later this afternoon unless anyone                                                                                
has any concerns.                                                                                                                                     
                                                                                                                                                      
Cheers!                                                                                                                                               
Michael    


On Sat, Dec 04, 2010 at 10:15:37PM -0700, Todd Ringler wrote:
> 
> Hi Michael,
> 
> Thanks for keeping this on the list. The proposed change to  
> accommodate different graph names looks fine to me.
> 
> I can't comment on the big-endian modification. I am happy to go with  
> it if no one voices concern.
> 
> Cheers,
> Todd
> 
> On Nov 29, 2010, at 1:25 PM, Michael Duda wrote:
> 
> >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
> >>
> >< 
> >changes_20101129 
> >.tar.gz>_______________________________________________
> >mpas-developers mailing list
> >mpas-developers at mailman.ucar.edu
> >http://mailman.ucar.edu/mailman/listinfo/mpas-developers
> 


More information about the mpas-developers mailing list