[mpas-developers] Restructuring high-level MPAS driver

[Michael Duda]

Hi, All.

I've updated the tar file at
http://www.mmm.ucar.edu/people/duda/files/mpas/mpas_newdriver.tar.gz
according to Phil's suggestion for less generic names. Now, the calling
structure looks like

   mpas_init()                     [module_mpas_subdriver]
        mpas_framework_init()      [module_mpas_framework]
        mpas_core_init()           [module_mpas_core]

   mpas_run()                      [module_mpas_subdriver]
         mpas_core_run()           [module_mpas_core]

   mpas_finalize()                 [module_mpas_subdriver]
        mpas_core_finalize()       [module_mpas_core]
        mpas_framework_finalize()  [module_mpas_framework]

If there are further comments, I'd be glad to address them; otherwise,
I'd like to propose committing the changes as they are in the tar file.

Cheers,
Michael


On Fri, Oct 29, 2010 at 11:40:55AM -0600, Jones, Philip W wrote:
> 
> Folks,
> 
> A couple of quick comments.
> 
> The structure:
>    call init()
>     call run()
>     call finalize()
> 
> Is certainly consistent with all other component and coupling frameworks, so should ease compatibility.  At some point, you'll probably need to specify arguments for input state, output state, some sort of time interval (for the run method) and returned error codes.
> 
> Another comment, that I think I've brought up previously, is that the generic names init, run, finalize (and probably others throughout mpas) are at risk for creating namespace conflicts in other components.  It'll be safer in the long run if mpas modules, public variables and public routine names add an mpas_ prefix or other string to reduce the possibility of conflict.  Similarly, there will be cases even within the framework where we will need to distinguish between component models, like MPAS_OcnInit  and MPAS_AtmInit, or something similar.
> 
> Finally, now that I've recommended making all the names longer with prefixes, I have run into compilers already (Absoft) that are having trouble with some of the long routine names (esp. Xylar's ;^) ).  We will probably need to deal with this at some point for portability.
> 
> Phil, engaging in drive-by software engineering...
> 
> 
> ---
> Correspondence/TSPA/DUSA EARTH
> ------------------------------------------------------------
> Philip Jones                                pwjones at lanl.gov
> Climate, Ocean and Sea Ice Modeling
> Los Alamos National Laboratory
> T-3 MS B216                                 Ph: 505-500-2699
> PO Box 1663                                Fax: 505-665-5926
> Los Alamos, NM 87545-1663
> 
> 
> 
> _______________________________________________
> mpas-developers mailing list
> mpas-developers at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/mpas-developers