Cicero-SCM-runner

[maritsandstad]

Hi,

Just to leave an issue that I will be attempting to make a Cicero-SCM-runner. I guess the appropriate thing to do is to make my own fork and the make a pull-request later. Sound ok?

best, Marit

[znicholls]

yep perfect!

On Wed, Sep 9, 2020 at 6:38 PM Marit Sandstad notifications@github.com wrote:

Hi,

Just to leave an issue that I will be attempting to make a Cicero-SCM-runner. I guess the appropriate thing to do is to make my own fork and the make a pull-request later. Sound ok?

best, Marit

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openscm/openscm-runner/issues/16, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFUH5G3EL4GW27HR4RIH7F3SE45IZANCNFSM4RBRB6CQ .

[maritsandstad]

Just a quick question; so when you run magicc you have executable binary somewhere that you run (I would need to do the same for cicero) and you set this as an environmental variable. I can't find exactly where that is set, or whether you ship with such an executable when people just install the runner (which maybe they can't really do yet, or they're expected to have the magicc executable from somewhere else). Sorry for the dumb question, I'm sure it would all be obvious for somebody else...

[znicholls]

At the moment it's all set with a .env file, but it's not really setup properly.

Anyway, for now the simplest is if you add an extra variable into our .env.sample file (see https://github.com/openscm/openscm-runner/blob/master/.env.sample) with a name e.g. CICERO_EXECUTABLE. Then you need to make a copy of that for yourself and same it in a file called .env (i.e. do cp .env.sample .env) and then make sure your CICERO_EXECUTABLE points to the right place.

Then, whenever you need it in your code, you can get the path to that executable using get_env (see https://github.com/openscm/openscm-runner/blob/a6df89fde9acafce95c592700575706df642c022/src/openscm_runner/utils.py#L9). Note that the environment variables are read from the .env file in this line (https://github.com/openscm/openscm-runner/blob/a6df89fde9acafce95c592700575706df642c022/src/openscm_runner/run.py#L15). That will only be run when you do import openscm_runner. Turns out this isn't a very smart way to do things, but @lewisjared and I haven't got around to fixing it yet and it should be good enough for now.

[maritsandstad]

Ok, a couple of questions: As you will have noticed, I have not managed to get anything together in time. I also have quite a bit of work to do to put it together. Is it still meaningful to try to get it up? Second, it seems from the test scenario data, that the number of emissions listed are quite limited. Should other emissions just be assumed to be zero?

[maritsandstad]

Also: Should the runs just go from 2015, or do I need to define historical data from somewhere?

[znicholls]

Is it still meaningful to try to get it up?

That's up to you and the Cicero team. It's the key to running the scenarios so without this piece, it won't be possible. Do you have some efforts already? You can make a PR then I can give you some tips maybe?

Should other emissions just be assumed to be zero?

This is slightly tricky. At the moment both MAGICC and FaIR take missing emissions from the RCMIP data. If you make a PR I can give you a hand.

Should the runs just go from 2015, or do I need to define historical data from somewhere?

You need to be able to take input data which only starts in 2015. What you do thereafter is up to you. Both MAGICC and FaIR bolt on their own internally hard-coded historical emissions (which are the same as the RCMIP emissions) and do runs from 1750 onwards.

[maritsandstad]

I do have a start but it is still a bit immature for a PR, but then I will try to get it to run and do a PR (will still be plenty of things to rectify...)

Taking historical from RCMIP sounds perfectly fine.

However, for future other emissions like CFCs etc. I can also take them from RCMIP, but are they the same in all ssps? Otherwise do I need to do some matching?

[znicholls]

We’ve just used SSP245 in all cases. There are plans to do something smarter, but that will happen elsewhere so for now just using SSP245 is fine.

On Fri, 18 Sep 2020 at 6:15 pm, Marit Sandstad notifications@github.com wrote:

I do have a start but it is still a bit immature for a PR, but then I will try to get it to run and do a PR (will still be plenty of things to rectify...)

Taking historical from RCMIP sounds perfectly fine.

However, for future other emissions like CFCs etc. I can also take them from RCMIP, but are they the same in all ssps? Otherwise do I need to do some matching?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/openscm/openscm-runner/issues/16#issuecomment-694727203, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFUH5G2A74BRP6ERLBWLYWDSGMJLRANCNFSM4RBRB6CQ .

[maritsandstad]

Ok, nice, at least relatively easy to adhere to

[maritsandstad]

So, I'm getting closer to something that resembles an actual adapter (or so I think anyway). There are quite a few moving parts in terms of files I have to use (previous input data, parameter sets etc. For now I'm making a subfolder with that stuff, hope that's an ok solution, otherwise I'd be happy to find a smarter solution). I am hopeful that I'll be able to put in an at least nearly functional pull-request this week. Is that a somewhat acceptable time frame? (I know this has been slow, but I don't think it really could have been all that much faster...)

[maritsandstad]

Additional dumb question; Do you know how I can supress warnings of "Filtered IamDataFrame is empty"? (To get the input, I filter for variables I need and check if the filter is empty to decide whether to take the data from the RCMIP ssp245 or from the given input. Then many of those filters will be empty, and I'd prefer not to get inundated with those warnings...)

[rgieseke]

The warning comes from this line I think:

https://github.com/IAMconsortium/pyam/blob/master/pyam/core.py#L1339

if len(idx) == 0:
            logger.warning('Filtered IamDataFrame is empty!')

Maybe something like

import logging
logging.getLogger('pyam').setLevel(logging.DEBUG)

can suppress these warnings.

Possibly best to switch this back to logging.warning after you're done with your filtering.

[znicholls]

Good suggestion! Only tweak, you'll want to set the logging level higher, not lower so it'll be

import logging
logging.getLogger('pyam').setLevel(logging.ERROR)

[rgieseke]

Whoopsie, thanks @znicholls! 😄

[maritsandstad]

Thank you both, that worked!

[maritsandstad]

Is there a full list of possible output variables with expected units somewhere, or is it just the RCMIP ones?

[znicholls]

Names aren't perfect (if you can use RCMIP names that's probably better but we can also do internal mappings if needed) but this should list should hopefully be obvious enough? Units don't really matter (scmdata will convert without much trouble if needed) but if you follow RCMIP units you won't go wrong.

If you can build it so adding more variables later (if needed) isn't a massive issue that would be ideal.

Key variables

        "Surface Air Temperature Change",
        "Surface Air Ocean Blended Temperature Change",
        "Heat Uptake",
        # concentrations
        "Atmospheric Concentrations|CO2",
        "Atmospheric Concentrations|CH4",
        "Atmospheric Concentrations|N2O",
        # ERFs
        "Effective Radiative Forcing",
        "Effective Radiative Forcing|Anthropogenic",
        "Effective Radiative Forcing|Aerosols",
        "Effective Radiative Forcing|Aerosols|Direct Effect",
        "Effective Radiative Forcing|Aerosols|Indirect Effect",
        "Effective Radiative Forcing|Greenhouse Gases",
        "Effective Radiative Forcing|CO2",
        "Effective Radiative Forcing|CH4",
        "Effective Radiative Forcing|N2O",
        "Effective Radiative Forcing|F Gases",

Extras if you have them

        "Heat Uptake|Ocean",
        "Effective Radiative Forcing|Aerosols|Direct Effect|BC|MAGICC Fossil and Industrial",
        "Effective Radiative Forcing|Aerosols|Direct Effect|BC|MAGICC AFOLU",
        "Effective Radiative Forcing|Aerosols|Direct Effect|OC|MAGICC Fossil and Industrial",
        "Effective Radiative Forcing|Aerosols|Direct Effect|OC|MAGICC AFOLU",
        "Effective Radiative Forcing|Aerosols|Direct Effect|SOx|MAGICC Fossil and Industrial",
        "Effective Radiative Forcing|Aerosols|Direct Effect|SOx|MAGICC AFOLU",
        "Effective Radiative Forcing|HFC125",
        "Effective Radiative Forcing|HFC134a",
        "Effective Radiative Forcing|HFC143a",
        "Effective Radiative Forcing|HFC227ea",
        "Effective Radiative Forcing|HFC23",
        "Effective Radiative Forcing|HFC245ca",
        "Effective Radiative Forcing|HFC32",
        "Effective Radiative Forcing|HFC4310",
        "Effective Radiative Forcing|CF4",
        "Effective Radiative Forcing|C6F14",
        "Effective Radiative Forcing|C2F6",
        "Effective Radiative Forcing|SF6",
        # # carbon cycle
        # "CO2_AIR2LAND_FLUX",
        # "CO2_AIR2OCEAN_FLUX",

[maritsandstad]

Ok, thanks that is helpful. And yes, the plan is to make it relatively (whatever that means) easy to include more variables later.

[maritsandstad]

Ok, finally made a pull request. I think that it in principle works (in terms of, getting inputs running and delivering outputs in the correct format, they should also be roughly calibrated as before, but I've not done much testing of the actual outputs). It's also not based environment variables, but rather on adding inputs as extra files.