{"action":"created","issue":{"url":"https://api.github.com/repos/MPAS-Dev/MPAS-Analysis/issues/20","repository_url":"https://api.github.com/repos/MPAS-Dev/MPAS-Analysis","labels_url":"https://api.github.com/repos/MPAS-Dev/MPAS-Analysis/issues/20/labels{/name}","comments_url":"https://api.github.com/repos/MPAS-Dev/MPAS-Analysis/issues/20/comments","events_url":"https://api.github.com/repos/MPAS-Dev/MPAS-Analysis/issues/20/events","html_url":"https://github.com/MPAS-Dev/MPAS-Analysis/issues/20","id":177238110,"number":20,"title":"Supports ingesting arbitrary MPAS output files (in general, input info from namelist and streams files)","user":{"login":"pwolfram","id":4295853,"avatar_url":"https://avatars.githubusercontent.com/u/4295853?v=3","gravatar_id":"","url":"https://api.github.com/users/pwolfram","html_url":"https://github.com/pwolfram","followers_url":"https://api.github.com/users/pwolfram/followers","following_url":"https://api.github.com/users/pwolfram/following{/other_user}","gists_url":"https://api.github.com/users/pwolfram/gists{/gist_id}","starred_url":"https://api.github.com/users/pwolfram/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pwolfram/subscriptions","organizations_url":"https://api.github.com/users/pwolfram/orgs","repos_url":"https://api.github.com/users/pwolfram/repos","events_url":"https://api.github.com/users/pwolfram/events{/privacy}","received_events_url":"https://api.github.com/users/pwolfram/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":13,"created_at":"2016-09-15T17:33:11Z","updated_at":"2016-11-29T17:00:25Z","closed_at":null,"body":"The MPAS analysis framework is expected to support stand-alone MPAS workflows, as well as ACME workflows. As such, the analysis framework should be capable of ingesting MPAS output, regardless of how it was generated.\n\nNOTE: This could imply that an input to the analysis framework should be the namelist and streams file used to generate the output, which can then be parsed to easily understand what output was generated, and where it should exist.\n"},"comment":{"url":"https://api.github.com/repos/MPAS-Dev/MPAS-Analysis/issues/comments/263630474","html_url":"https://github.com/MPAS-Dev/MPAS-Analysis/issues/20#issuecomment-263630474","issue_url":"https://api.github.com/repos/MPAS-Dev/MPAS-Analysis/issues/20","id":263630474,"user":{"login":"xylar","id":4179064,"avatar_url":"https://avatars.githubusercontent.com/u/4179064?v=3","gravatar_id":"","url":"https://api.github.com/users/xylar","html_url":"https://github.com/xylar","followers_url":"https://api.github.com/users/xylar/followers","following_url":"https://api.github.com/users/xylar/following{/other_user}","gists_url":"https://api.github.com/users/xylar/gists{/gist_id}","starred_url":"https://api.github.com/users/xylar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/xylar/subscriptions","organizations_url":"https://api.github.com/users/xylar/orgs","repos_url":"https://api.github.com/users/xylar/repos","events_url":"https://api.github.com/users/xylar/events{/privacy}","received_events_url":"https://api.github.com/users/xylar/received_events","type":"User","site_admin":false},"created_at":"2016-11-29T17:00:25Z","updated_at":"2016-11-29T17:00:25Z","body":"@milenaveneziani and @pwolfram, this issue is one I'm willing to work on as I have time in the next week or two.  The logistics of mapping variable names, while tedious, seems relatively straightforward to me.  What isn't so clear is how to identify which versions of each component are being used with a given analysis and, equally important, what the possible options are.\r\n\r\nFor this reason, I'm coming around to @pwolfram's idea of just have a list of possible names for each variable and try each (presumably in arbitrary order or perhaps in the order given in the config file).  This approach would work as long as there aren't conflicts where (as I already mentioned) the new name of one variable is the old name of another.  Perhaps this situation is too unlikely to be worth considering.  This approach has the clear advantage of being easy to extend to new versions without much extra thought.\r\n\r\nAnother approach would be to have a section in the config file for each version of MPAS-O (and one for each version of MPAS-SI) that we want to support with some kind of an identifying name (perhaps something like `ACME_alpha7` or `v5.1`).  This section would give the variable mapping for that version.  We would need to add the MPAS-O and MPAS-SI version names to the PreAndPostProcessingScripts repo somehow, e.g. by having an ACME version name that could be used to select the corresponding MPAS-O and MPAS-SI version.\r\n\r\nMy tendency is to first try implementing the first (\"quick-and-dirty\") approach that doesn't care about versions and to move to the more complex mapping that knows about version numbers if/when that seems necessary.  I'll try to write this so we can switch to the second approach in the future if needed without needing to make modifications to the analysis scripts themselves.\r\n\r\nLet me know if that all sounds okay to you two."}}
{"actor":{"display_login":"xylar"}}