Extend information about native6 support on RTD

[Peter9192]

This PR addresses the lack of documentation for the support of data in their native format as discussed here. So far, two notes were available in the contributing pages here and here, but anyone looking for information on cmorizing datasets will probably look at the input data page here. Therefore, I add a description there, and some links to find it from the other notes as well.

Tasks

• Create an issue to discuss what you are going to do, if you haven't done so already (and add the link at the bottom) (see this thread
• Give this pull request a descriptive title that can be used as a one line summary in a changelog
• Make sure your code is composed of functions of no more than 50 lines and uses meaningful names for variables
• Circle/CI tests pass. Status can be seen below your pull request. If the tests are failing, click the link to find out why.
• Preferably Codacy code quality checks pass, however a few remaining hard to solve Codacy issues are still acceptable. Status can be seen below your pull request. If there is an error, click the link to find out why. If you suspect Codacy may be wrong, please ask by commenting.
• Please use yamllint to check that your YAML files do not contain mistakes

[Peter9192]

I can't figure out how to link to a different part of the documentation using a relative link with the rst syntax. Some help would be appreciated.

I guess it should be something like

:ref:`obtaining input data<observations>`

but that doesn't work. I want to link here

The link in the note here is also broken. I'd like to fix that one as well. But then, I'd need a cross-reference from Core to Tool docs, no? How to do that?

[bouweandela]

Try adding

.. some_title:

above the section that you want to link to. You can then create the link with:

:ref:`some_title`

[Peter9192]

Thanks Bouwe! It worked once I put an underscore before _some_title (only in the label, not in the reference).

[bouweandela]

Sorry for the typo

[SarahAlidoost]

@Peter9192 thank you. I made some minor comments on the changed files. However, the text benefits from a re-structuring and more clarifications.

First, it is useful if there are two separate sections for "CMORization" and ‘‘CMORization on the fly”. The latter explains what the purpose is, what are the instructions like the path and drs in the user-config-example file, and introducing datasets in the recipe. We can use introducing ERA5 here as an example. Please note that the native era5 contains both hourly and monthly datasets.

Second, we need a separate section (e.g. subsection under ‘cmorization as a fix’) to use the recipe_era5.yml. Again this section should explain what the purpose is, what are the instructions like the path and drs in the user-config-example file, and introducing datasets in the recipe, and also the command line to run it.

[Peter9192]

Hey @SarahAldt ,
Thanks for the review. I addressed your comments. I don't understand what you mean with the general comment about restructuring, though. There are 2 subsections, right? 1 for cmorization with a script, 1 for cmorization as a fix.

[Peter9192]

@SarahAlidoost I implemented what we discussed. Is it better like this?

[SarahAlidoost]

@Peter9192 thanks for the improvements. @mattiarighi could you please have a look and merge? thanks.