Use std instead of std_dev in recipe_esacci_lst.yml

[valeriupredoi]

Description

std_dev is not supported as multimodel statistic, replacing it with std

• Closes Using std_dev as multimodel statistic is no longer accepted after ESMValCore PR 673 got merged #2521

---

Before you get started

• ☝ Create an issue to discuss what you are going to do

Checklist

It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.

• 🛠 This pull request has a descriptive title
• 🛠 Tests run successfully
• 🛠 All checks below this pull request were successful

[zklaus]

I think this is wrong. Please have a look at https://github.com/ESMValGroup/ESMValCore/blob/7c58c80dbb5c53147ccb4b20b71200ccfae4adf0/esmvalcore/preprocessor/_multimodel.py#L57. We need to understand better what is going on before we can jump into mucking with the code.

[schlunma]

I think this is wrong. Please have a look at https://github.com/ESMValGroup/ESMValCore/blob/7c58c80dbb5c53147ccb4b20b71200ccfae4adf0/esmvalcore/preprocessor/_multimodel.py#L57. We need to understand better what is going on before we can jump into mucking with the code.

Agreed. Looks like ESMValGroup/ESMValCore#673 undid some of the changes from ESMValGroup/ESMValCore#1150. This needs be fixed in the core.

BTW, I thought the CI runs use the released version of the core? Why did the merge of ESMValGroup/ESMValCore#673 affect this?

[schlunma]

I will open a PR for that in the core

[valeriupredoi]

thanks guys, I be closing this then! Manu, there is one (powerful) GA test that runs the tests with the latest Core main and that's the only one affected via Core/673

[zklaus]

And good thing we have it. Thanks for that, @valeriupredoi ! You're a 🌟

PS: This is the kind of stuff that would be avoided or at least much less likely with a workflow that is based on rebase instead of merge.

[valeriupredoi]

And good thing we have it. Thanks for that, @valeriupredoi ! You're a star2

shucks 😊

Yeah, agreed about rebasing, only problem I see is users that are not that familiar with github getting stuck with it and being scared s**less of the errors they may get from doing that. Or we can just do it at merge point on GH only?

[zklaus]

I mean the point is to keep the history clean at all times and make really clear which changes are actually coming from a particular PR. Not much point in doing this after everything has been thoroughly mangled over years of merging. Also, very difficult to do at that point.