oceanmodeling / ufs-weather-model

This repo is forked from ufs-weather-model, and contains the model code and external links needed to build the UFS coastal model executable and model components, including the ROMS, FVCOM, ADCIRC and SCHISM plus WaveWatch III model components.
https://github.com/oceanmodeling/ufs-coastal-app
Other
2 stars 3 forks source link

Compile mulitiple model components #13

Closed saeed-moghimi-noaa closed 3 months ago

saeed-moghimi-noaa commented 9 months ago

Hi @pvelissariou1

Please describe what we need to do and how to coordinate with @uturuncoglu.

Thanks

uturuncoglu commented 8 months ago

@pvelissariou1 Please let me know what do we need to have single executable for all the applications. I think we need to minimize the number of application defined in the CMake file. Since, we could compile the model with spack-stack, I think we could spend little bit more time for the extra dependencies. Is there any limitation currently in the components in terms of used Metis library. I think there is no any other library that is shared among the components. Right?

pvelissariou1 commented 8 months ago

@uturuncoglu In general this should be a user request from the top level build script. Now, regarding the libraries only METIS is shared by the components (FVCOM, ADCIRC). WW3 has the options to use either SCOTCH or METIS/ParMETIS at this point. SCHISM uses ParMETIS (internal or external), I think we should stick with its internal ParMETIS if possible or to allow the user to download and compile PerMETIS (as in CoastalApp). I don't think it is advisable to include ParMETIS in spack-stack. These are the depedencies so far. We need to start thinking about developing a portable build system for UFS-Coastal. Need to discuss this in the upcoming meeting with the UFS developers.

uturuncoglu commented 8 months ago

@pvelissariou1 I think we could make it through the interfaces under UFS Coastal without nay modification in the component build system. That will allow us to standardize common dependencies and use single location for them. Again, it seems that spack-stack is working fine in terms of providing dependencies and also Hernan is used it in their side. The only think is that we need to provide a script in the app level to handle installation which is in my list. I fixed couple of issues with the component builds under GNU and I think they are fine now. Let me work little bit more about chasing dependencies and modify the build to use external library dependencies too.

pvelissariou1 commented 8 months ago

@uturuncoglu Please review and merge my PR in UFS-Coastal

pvelissariou1 commented 8 months ago

@uturuncoglu I believe that it shouldn't be a build system connected with the APP level in UFS-Coastal. I think we should at some point spent time to develop a build system that is separated from the APP level.

uturuncoglu commented 8 months ago

@pvelissariou1 Okay. We could discuss it more. Just to clarify, when I say app it is ufs-coastal-app and I think all the workflow (creating configuration, preparing IC etc.) related steps and also capability to provide additional tools like handling dependencies etc. can be implemented in that level. Having build in the app level is a kind of convention in the other applications. Here are the following examples,

There is also global workflow. Anyway, we would like to follow the same convention also in UFS Coastal but there is no any strict rule about it.

pvelissariou1 commented 3 months ago

This task is completed.

uturuncoglu commented 3 months ago

@pvelissariou1 As I know we have some issues with the Metis library. Different components was requiring to use different versions and it was creating issue. I am not sure this is solved or not but if you don't mind could you confirm that we could compile ADCIRC+FVCOM+SCHSIM+WW3+ROMS together (along with CMEPS and CDEPS) and create single executable. I was thinking that we are far from having it. Maybe I missed something. Thanks.