This topic is a catch-all location for feedback for the ACCESS-rAM3 2.0-beta Release.
Please reply to this topic if you have feedback on the ACCESS-rAM3 2.0-beta. Feedback can be to point out problems encountered, or positive to highlight what worked well.
If your feedback is involved and will require specific help feel free to
make a topic on the ACCESS-Hive Forum.
If you’re not sure, reply here and your query can be moved to a separate topic if required.
Checked out the RAS u-bu503 and switched to the nci_access_ram3 branch.
Trying to load the GUI with rose edit results in the following error:
Hi @bethanwhite,
That is really strange. Can you please try moving or deleting that u-bu503 copy and checking out the branch directly using:
rosie checkout u-bu503/nci_access_ram3.
I just did the direct checkout and the rose edit command is working for me.
Thanks @cbengel, that’s odd! Can confirm the command line direct checkout of the branch works. Guessing the original branch switch didn’t execute cleanly for some reason?
@cbengel @heidi can confirm u-bu503/nci_access_ram3 produces ancils for the default Lismore case runs successfully 
OSTIA in rAM3: Running the rAM3 branch u-by395/nci_access_ram3 with OSTIA SSTs set to true fails because the suite is set to expect each user to have the OSTIA data in their own /scratch/$PROJECT/$USER directory.
For the Flagship config we use OSTIA in vk83:
global_ostia_dir="/g/data/vk83/prerelease/data/restricted/ukmo/access-ram/ostia_anc/ostia_sst_ukmo_global_generic”
It would make sense to have the rAM3 suite point here if OSTIA is used, rather than require each user to extract the data from MOOSE independently.
The issue being that vk83 would also need to be added to the suite’s storage flags and a user would need to have vk83 access.
Hi @bethanwhite,
For the tutorial I put some pre-produced OSTIA data into vk83 as an example.
To create your own OSTIA files please look into running the “Ostia Ancillary Suite” (OAS) suite id u-dk517.
The details are in https://access-ram3-configs.access-hive.org.au/initial_conditions/replace_sst_seaice/#update-the-ostia-settings
By the way, apologies for all the broken in the release statement and config-docs. The ACCESS-Hive team are working on an upgrade and the config-docs have been fixed but not in that preview. The full-release should have properly working links.
Also, thank you for pointing out the previous error with the switching of the branch. This is very strange and something for the community to be aware of.
We (actually @Paul.Gregory) have noticed that with rAM3 2.0 users are reporting the ancillary bug with canopy height NaN over Macquarie island. This was fixed in previous releases by increasing the spiral search radius, but with the re-alignment to the Met Office suite, this fix has been lost. Is it possible to include this again?
Yes. Sorry this was a misunderstanding.
I thought that u-bu503 had the fix in it already, but I think it has the new URBAN content you folded in but not the spiral search. I will look into updating out u-bu503 branch.
Apologies for the confusion.
Maybe we can discuss this offline, but do you want me to fix it by using your RAS branch or in the actual code? (asking because of the version change).
Up to you. It’s made a bit complicated because it’s part of the ANTS CONTRIB source code. So to fix you’d need to make a dev branch from the relevant ANTS CONTRIB source, update, then point the suite to the branch. That’s what I did last time.
A more robust fix would be to update in the actual ANTS trunk, but that means going through the Met Office processes (and I’m not sure they are still updating the MOSRS version?).
OK. Leave it with me 
