-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Forcing feedback POD issue #662
Comments
@aradhakrishnanGFDL @jtmims has done some exploring and found that the json file for your catalog still has time_range in the aggregations block, which is likely causing your problem. Try removing it and see if that gets you further. |
The groupby_attrs do not have time_range. /home/a1r/github/noaa-gfdl/catalogs/c96L65_am5f7b10r0_amip30_0814.json Right? @jtmims are you referring to groupby_attrs or the joinExisting, because I expect the latter to be present to perform the aggregation across time.
|
From testing, either/or can be the solution. If you keep the join_existing in the aggregations you have to also include time_range in 'groupby_attrs' in order for intake_esm to grab that attribute and make it accessible in xarray. In the current version of the framework, I believe @wrongkindofdoctor has removed 'time_range' from join_existing portion of the aggregations. Both of the options seem to make intake_esm happy to populate these values. |
intake-esm and xarray can work with time in join_existing and not in groupby_attrs. Example POD and the corresponding catalogs are an example. Let me know if I missed something. We can settle for a temporary fix where I edit the json schema from my end, but we want to use these catalogs outside of MDTF in our user analysis scripts, so we can revisit this later and see what is sustainable fix. |
@jtmims Going for the fix from my end, let me know if this catalog looks fine. I removed the join_existing time_range part, at least I think I did. /home/a1r/github/noaa-gfdl/catalogs/c96L65_am5f7b10r0_amip30_0814.json |
The json with removed join_existing didn't do it. But, let me know if it worked for you and I missed something. I am also curious if this issue could be something to do with no data preprocessing done as the log message says ..
The other possibility is that perhaps my input json (runtime) do not have the conventions set correctly? |
@aradhakrishnanGFDL the issue occurs during the check to make sure the files are in the correct order to run xr.concat(). I have just sent a PR (#665) that changes this sort to not rely on information supplied by esm intake. Hopefully, this fixes the issue! |
that's progress, thanks! Went further along.. the logs do not have additional info. But I can send pointers on GFDL's dpdev when you need. The errors are the same regardless of the join_existing, so that's ruled out.
|
@aradhakrishnanGFDL The POD is not generating figures for some reason. I don't see an issue with the figure directory paths at first glance. There is nothing in the forcing_feedback/forcing_feedback.log file, correct? |
Oh, there is a hint there about kernel file missing. What is that?
|
I think I got it, the OBS data is missing
@jtmims I am using your obs_data directory. Is forcing feedback POD's obs data present there? Perhaps I should use the oar.gfdl.mdtf obs data path? |
I will substitute with /home/oar.gfdl.mdtf/mdtf/inputdata/obs_data/forcing_feedback/ and report back |
@aradhakrishnanGFDL I was just about to notify you of this. I've been using the oar.gfdl.mdtf obs data path as of now. It saves space on my directory. Some calculations done in Forcing Feedback require a file found in OBS_DATA. |
@aradhakrishnanGFDL @jtmims I ran the FF POD with @aradhakrishnanGFDL's test catalog and obs data. There are some issues with the plotting routines in the POD related to the data itself and the color bar routines shown in the forcing_feedback.log file. You can try re-running with a different date range, but otherwise, this is a POD-specific issue that does not appear to stem from the framework preprocessing.
|
@wrongkindofdoctor What data set was used? It seems to gel well with the AM5 that I had on the workstation. It plotted all of the plots when running with the latest main branch. |
@jtmims Glad your run succeeded! yay. Looking at @wrongkindofdoctor's comment on the time period selections and referring to the POD documentation, it appears that 2003-2014 has to be used for this POD, which is also the same selections you have in your config file. If I bypass my disk space issues, that's what I will do next, and see if it succeeds. AM5 dev experiment - /archive/am5/am5/am5f7b10r0/c96L65_am5f7b10r0_amip |
@aradhakrishnanGFDL @jtmims and I have been discussing the possibility that the container may not be able to mount correctly to archive and/or the way archive files are stored prohibits accessing them properly. We advise transferring a subset of the files to your workstation (one of the /local/ or /net directories should have enough space) and building a catalog referencing that data directory to avoid file read issues. |
The storage issue is on a VM that has different file systems. /archive mount works just like any other file system mount, but good to verify this! The approach suggested is quite cumbersome for a user running analysis on catalogs generated from modeling workflows. But I will keep this in mind..I hadn't thought about this, I will hope for some success with the current setup. |
@aradhakrishnanGFDL Okay, so I just ran ffb for the years 2003-2014 using the original catalog you sent in this thread (/home/a1r/github/noaa-gfdl/catalogs/c96L65_am5f7b10r0_amip30_0814.json). It has completed the run and plotted everything it needed to. Please keep me updated if you find anything out about the container volume mounting! |
Summarizing an offline thread: My catalog points to this /archive/am5/am5/am5f7b10r0/c96L65_am5f7b10r0_amip/gfdl.ncrc5-deploy-prod-openmp/pp. @jtmims's catalog points to the /local/home subset of relevant data from /archive/am5/am5/am5f7b10r0/c96L65_am5f7b10r0_amip/gfdl.ncrc5-deploy-prod-openmp/pp. This catalog /home/a1r/github/noaa-gfdl/catalogs/c96L65_am5f7b10r0_amip30_0814.json or /home/a1r/testing/runtime_config_am5test_jmims.jsonc (this uses the same experiment @jtmims uses, but the data in /local is not exactly what's reflected in archive) can be used in testing. I have tested the behavior with and without the container, and the following plots are missing in both. (But there are several other plots (and all netcdf output) generated - so does not look like a container issue or an /archive mount/access issue) ERROR: Missing '$WORK_DIR/forcing_feedback/model/forcing_feedback_maps_WaterVapor.png'. Reference - I used this for testing without container: So, what might be different? catalog or its the state of the source data? It sounds like reaching out to the POD developer makes sense to me right now, if another person can use the my config or catalog and replicate results. Let this issue stay open. |
@jtmims any update on this? |
@aradhakrishnanGFDL Offline discussion and review suggests that this an issue with the POD computation not outputting results that it can plot within whatever bounds that the POD has set for the plot routine with this specific data subset. I suggest reaching out to the POD developers for more information. The framework team has other development tasks to prioritize this week, and will revisit the issue when time allows. In the mean time, I suggest trying to run the container with the Wheeler-Kiladis or EOF500_hpa PODs that have been consistently working in our tests, or selecting a different POD to try if all of the required variables are present in the dataset. |
I will look into testing with an alternate POD. Note that these tests are without container. |
New issues running forcing feedback POD. Changed enddate to 198401 to get rid of another error with 198012.
New catalog with standard_name fixed is here at GFDL /home/a1r/github/noaa-gfdl/catalogs/c96L65_am5f7b10r0_amip30_0814.json
"case_list":
{
"atmos_cmip":
{
"model": "am5",
"convention": "CMIP",
"startdate": "198001",
"enddate": "198412"
}
},
The text was updated successfully, but these errors were encountered: