How to test meta-data changes in the rose edit GUI in lfric?

[MichaelWhitall]

Hi all, sorry me again!

I noticed with interest the new box on the lfric_apps ticket summary form:

If modifying any rose metadata, have you checked the metadata behaves correctly by loading in the rose edit gui? | YES/NO/NA

How do you actually do this? I've so far failed to find any guidance in the working practices.

I tried just firing up
"rose edit"
or
"rose config-edit -M "
in a rose-stem app directory,
but these attempts have all failed with the GUI giving errors about not being able to find the meta-data. The problem is that there isn't a single rose-meta directory you can point to in lfric_apps; there are various different rose-meta directories for the different components. But the rose-app.conf files just have a single "meta=" field for everything, so its impossible!

I also took some guesses and tried pointing the "meta=" field in rose-app.conf to:
applications/lfric_atm/rose-meta/lfric-lfric_atm/HEAD
or
science/gungho/rose-meta/lfric-gungho/HEAD
in my branch working copy.

But then rose edit falls over complaining it can't find a path it wants to look for inside the directory specified in "meta=". (it refers to things inside a directory called "components/driver/rose-meta", which I can't find anywhere in lfric_apps).

Does anyone know where I need to point "meta=" to correctly test my branch meta-data when I open an lfric_apps rose-app.conf file in the GUI? Any chance we can have some guidance on this in the working practices?

Cheers!
Mike

[james-bruten-mo]

Hi again :)

The answer is that you need to have a copy of LFRic Core metadata available - obviously it's best to use whatever version of core you have in your dependencies.sh file. You'll need to checkout a working copy of that core version, and then do export ROSE_META_PATH=/path/to/core. Then you should be able to run rose edit successfully.

This is probably lacking in detail in the working practices. I'll update that in a PR for Upgrade Macros I have open.

[iboutle]

Thanks! I think it is a growing problem as the user base grows - the GUI is essentially unusable currently so everyone is just editing namelists by hand, which comes with plenty of dangers. I think you're right that long-term we want a solution which matches what other repos do (and if that means we have to reorganise the metadata directories I think that's fine), I just wondered if a stop-gap of having a central path people could export as their ROSE_META_PATH might make things a bit easier.

[james-bruten-mo]

Given some of the code I've already written for Macros in LFRic I suspect a wrapper script using that to call rose edit would be straightforward and potentially a better solution than a temporary place for the metadata. I'll have a look into that and also contact Dave M about centrally installing the metadata.

[MichaelWhitall]

Thanks lots for this discussion; d'oh I share your concerns about people generally just not using the GUI rather than going to the trouble of checking out a working copy of lfric_core (e.g. all sorts of problems can creep into work-flows if people change switches by hand without applying the triggering from the meta-data).

If I understand correctly, it was the splitting of lfric_apps and lfric_core into separate repositories that broke the meta-data? Does anyone know why this had to be done?

As hinted at below, I found a sort-of work-around which is (if you're using an lfric_apps branch), in your working copy, in the file:
science/gungho/rose-meta/lfric-gungho/HEAD/rose-meta.conf
Delete the line
import=components/driver/rose-meta/lfric-driver/HEAD
(this is the main reference to a path in lfric_core which breaks the meta-data if it can't be found).

You still get some errors in the GUI about meta-data (there must be some more references to things in the lfric_core rose-meta buried elsewhere in lfric_apps), but at least if you can get passed the initial "no such file or directory" problem when it tries to import that file then the GUI will load and format everything correctly for the physics namelists. The main downside is it disables triggering due to the remaining errors, and its the triggering we really want for the sake of keeping settings consistent with eachother!

[iboutle]

That sounds great James, thanks!

Mike - I think the general aim is that the metadata should live with the code it represents. It's an issue we've been battling with for years trying to use Jules's own metadata in the UM. The GUI didn't work particularly well before the repo split, since you still had to source the metadata directly (rose edit wouldn't find it like it does for other repos), so having to source it from different places isn't the only issue!

[iboutle]

p.s. I updated the metadata notes on https://code.metoffice.gov.uk/trac/lfric/wiki/GhaspSupport/PhysicsHandsOn#Metadata as they were a bit out-of-date

[MichaelWhitall]

Update:
It looks to me like
science/gungho/rose-meta/lfric-gungho/HEAD/rose-meta.conf

which contains:

import=components/driver/rose-meta/lfric-driver/HEAD
      =science/jules_interface/rose-meta/jules-lfric/HEAD
      =science/socrates_interface/rose-meta/socrates-radiation/HEAD
      =science/um_physics_interface/rose-meta/um-aerosol/HEAD
      =science/um_physics_interface/rose-meta/um-boundary_layer/HEAD
      =science/um_physics_interface/rose-meta/um-chemistry/HEAD
      =science/um_physics_interface/rose-meta/um-cloud/HEAD
      =science/um_physics_interface/rose-meta/um-convection/HEAD
      =science/um_physics_interface/rose-meta/um-iau/HEAD
      =science/um_physics_interface/rose-meta/um-microphysics/HEAD
      =science/um_physics_interface/rose-meta/um-orographic_drag/HEAD
      =science/um_physics_interface/rose-meta/um-spectral_gwd/HEAD
      =science/um_physics_interface/rose-meta/um-stochastic_physics/HEAD

is some kind of master meta-data file that puts all the bits together, so presumably that is the one I want the lfric_atm app to point to :) The reason my attempts to use this are failing is because the first line:
"components/driver/rose-meta/lfric-driver/HEAD"
seems to be a path that doesn't exist?

All the other paths imported above DO exist in the lfric_apps repository; its just that first one that doesn't. I wonder what happens if I just delete that line? ;) ...