NOAA-EMC / WW3

WAVEWATCH III
Other
258 stars 516 forks source link

The build system does not build tools in case of coupling #1025

Open uturuncoglu opened 1 year ago

uturuncoglu commented 1 year ago

Is your feature request related to a problem? Please describe. It seems that the build system does not build tools such as ww3_grid in case of coupling (when UFS_ is defined). At this point, I am workin on Coastal App project that aims to use up-to-date version of the uff-weather-model and it would be nice to install those tools and make available for the app.

Describe the solution you'd like This is one line change in the build system by removing following line, https://github.com/NOAA-EMC/WW3/blob/3eb8161fdc999f4046fac7d77febff70c399c4f8/model/src/CMakeLists.txt#L139

Describe alternatives you've considered This can be also done in app level but it would be more complicated. We could also make tool build option dependent. So, we could introduce another option like BUILD_TOOLS etc. and not make it only depend on building coupled or standalone version of the model.

Additional context N/A

JessicaMeixner-NOAA commented 1 year ago

@uturuncoglu this for now is by design. In the other coupled UFS applications (HAFS, GFS/GEFS) we have a seperate build script that builds the ww3_grid and other utilities and I'd recommend following the same approach for the coastal act. One of the reasons is most of the pre and post processing routines should actually be built with different switches. Here's a script that could be of use to follow: https://github.com/NOAA-EMC/global-workflow/blob/develop/sorc/build_ww3prepost.sh

Please let me know if you have any questions.

uturuncoglu commented 1 year ago

@JessicaMeixner-NOAA I did not know about that convention and that is totally understandable but if we include another option in top level CMake just for building tools then user is able to build it internally without using a script in the app level. The default could be not to build the tools in this case. If you still want to keep like this that is fine and I could integrate it with the app.

JessicaMeixner-NOAA commented 1 year ago

@uturuncoglu I'm unsure if any top level cmake option would actually simplify this second script that you'd need to build the tools with because you'd still need to modify your switch before building. I know that we did that in a really old version of NEMS, but we took that capability out by request. If we need to hop on a quick call so I understand better next week we could do that, otherwise I'd recommend moving forard like HAFS and GFS/GEFS with the simple build script for the tools.

aliabdolali commented 1 year ago

CMAKE handles any switch combination automatically, so all executables can be built w/o changing the switch.

uturuncoglu commented 1 year ago

@aliabdolali Thanks for your help. As I see from the current version of the build system, there is no any option to build tools when you are building ESMF/NUOPC coupling interface. That might be nice to have it. Maybe I am missing something.

aliabdolali commented 1 year ago

@aliabdolali Thanks for your help. As I see from the current version of the build system, there is no any option to build tools when you are building ESMF/NUOPC coupling interface. That might be nice to have it. Maybe I am missing something.

Check with @DeniseWorthen. The capability is embedded in WW3, and can be leveraged to the meshcap. I just corrected the statement about WW3 CMAKE. Your idea is great.

DeniseWorthen commented 1 year ago

Thanks @aliabdolali but I don't really know anything about the various tools which are built by WW3. The only one I've used is ww3_grid to generate mod_def files. I've always made use of the run-time netcdf output capability of the mesh cap and have never needed to look at point or track output.

@uturuncoglu I know Mariana recently added the capability to generate mod_def files 'on the fly' by building ww3_grid and running it at the time the model run is submitted, but that is in CESM of course.

uturuncoglu commented 1 year ago

@DeniseWorthen Thanks. That is really helpful. Anyway, I think it won't hurt if we could introduce another CMake option to build tools. By default this could be OFF and it won't change anything in terms of UFS Weather Model but it could give flexibility to user to have them in place.

uturuncoglu commented 1 year ago

@JessicaMeixner-NOAA @aliabdolali @DeniseWorthen I have a small modification that allow building tools optionally. You can see the diff in the following link, https://github.com/NOAA-EMC/WW3/compare/dev/ufs-weather-model...uturuncoglu:WW3:feature/coastal_app?expand=1. Let me know if you want to have PR for it.

JessicaMeixner-NOAA commented 1 year ago

@uturuncoglu personally I still think building twice with the separate build with appropriately modified switch is the way to go. I'm not a cmake expert, but I don't see where you've modified the switch to make sure the tools are built correctly here. If you make a PR for this, please push it to the develop branch instead of dev/ufs-weather-model for review.