Moving adas download cache file location out of populate method

[Mateasek]

I think it would be nice if the list of files from adf11 (and all other file formats) would be accessible without calling the populate method in create.py.

I would like to create a unittest comparing interpolated data with the adas original data to test for any inconsistencies.

I suggest moving the dictionaries holding the element information and the download_cache paths out of populate method (it can be kept in the same file). This way it could be imported from the unittest methods. The unittest could then download the file, if it was missing, and could parse and get the raw data directly.

What do you think @mattngc, @CnlPepper ?

[Mateasek]

Reading the issue I think I have to describe it a little bit better.

Currently (if I am not mistaken) all the information about openadas data files are stored in variables within the populate method. This way they can't be accessed from outside the file/method. This is I think pitty since it could be useful elsewhere, especially if used together with the _locate_adas_file which returns the path to the sought file and downloads it if it is missing.

I would really need to have the described access to build up unittests. I sketched what I have in mind in the commit 5f0a724

[mattngc]

I'm not sure why you need this change for your unit tests? Can you explain it a bit more?

The data files in that populate method are not meant to be exhaustive. The idea is that actually users will curate their own atomic data based on what they need for their work. They would collect or even create custom ADF files using existing ADAS workflows and then install these files into their local repositories with the install_adf*() methods. The file list we provide in the populate method is really just a minimal default list that Alex and I curated for beginners. Maybe the labeling of that file and method should have been clearer to explain its purpose better.

Also, knowing all this it now might not make sense to have this as a unit test. Since a user might install some new data they are working with, which not breaks the unit test because it deviates slightly.

I think we need to think this through a bit more.

[Mateasek]

Ah alright, now I think I get the Idea.

[mattngc]

I probably didn't document it well enough :)

[Mateasek]

Well this kind of explains your comment in issue #32. Lets close this and continue there?Because this proposal was linked to the unittest feature.