{"action":"created","issue":{"url":"https://api.github.com/repos/StrikeNP/trac_test/issues/319","repository_url":"https://api.github.com/repos/StrikeNP/trac_test","labels_url":"https://api.github.com/repos/StrikeNP/trac_test/issues/319/labels{/name}","comments_url":"https://api.github.com/repos/StrikeNP/trac_test/issues/319/comments","events_url":"https://api.github.com/repos/StrikeNP/trac_test/issues/319/events","html_url":"https://github.com/StrikeNP/trac_test/issues/319","id":334629904,"node_id":"MDU6SXNzdWUzMzQ2Mjk5MDQ=","number":319,"title":"Check accuracy of SCM simulations at small timestep (Trac #319)","user":{"login":"StrikeNP","id":2577059,"node_id":"MDQ6VXNlcjI1NzcwNTk=","avatar_url":"https://avatars0.githubusercontent.com/u/2577059?v=4","gravatar_id":"","url":"https://api.github.com/users/StrikeNP","html_url":"https://github.com/StrikeNP","followers_url":"https://api.github.com/users/StrikeNP/followers","following_url":"https://api.github.com/users/StrikeNP/following{/other_user}","gists_url":"https://api.github.com/users/StrikeNP/gists{/gist_id}","starred_url":"https://api.github.com/users/StrikeNP/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/StrikeNP/subscriptions","organizations_url":"https://api.github.com/users/StrikeNP/orgs","repos_url":"https://api.github.com/users/StrikeNP/repos","events_url":"https://api.github.com/users/StrikeNP/events{/privacy}","received_events_url":"https://api.github.com/users/StrikeNP/received_events","type":"User","site_admin":false},"labels":[{"id":971577014,"node_id":"MDU6TGFiZWw5NzE1NzcwMTQ=","url":"https://api.github.com/repos/StrikeNP/trac_test/labels/Migrated%20from%20Trac","name":"Migrated from Trac","color":"FFFFFF","default":false},{"id":971577274,"node_id":"MDU6TGFiZWw5NzE1NzcyNzQ=","url":"https://api.github.com/repos/StrikeNP/trac_test/labels/clubb_src","name":"clubb_src","color":"FFFFFF","default":false},{"id":971577020,"node_id":"MDU6TGFiZWw5NzE1NzcwMjA=","url":"https://api.github.com/repos/StrikeNP/trac_test/labels/defect","name":"defect","color":"FFFFFF","default":false},{"id":971578548,"node_id":"MDU6TGFiZWw5NzE1Nzg1NDg=","url":"https://api.github.com/repos/StrikeNP/trac_test/labels/meyern@uwm.edu","name":"meyern@uwm.edu","color":"FFFFFF","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":12,"created_at":"2018-06-21T19:40:03Z","updated_at":"2018-06-22T15:08:39Z","closed_at":null,"author_association":"OWNER","body":"CLUBB has several Cu benchmark cases: BOMEX, RICO, and LBA.  In the past, when we've run these case with small timestep (e.g. 1 s), the cloud fraction has been much too large (e.g. 1 instead of 0.1).  \n\nMore recently, I have found that RICO has too much cloud fraction if the timestep is 1 s but the grid has 128 levels.  However, if the grid spacing is reduced to 40 m, then it works again.\n\nWe should re-check whether or not this is still a problem.\n\nWhile we're at it, for thoroughness, let's check all benchmark CLUBB cases.\n\nAttachments:\n\n[plot_explicit_ta_configs.maff](https://github.com/larson-group/trac_attachment_archive/blob/master/trac_test/822/plot_explicit_ta_configs.maff)\n[plot_new_pdf_config_1_plot_2.maff](https://github.com/larson-group/trac_attachment_archive/blob/master/trac_test/822/plot_new_pdf_config_1_plot_2.maff)\n[plot_combo_pdf_run_3.maff](https://github.com/larson-group/trac_attachment_archive/blob/master/trac_test/822/plot_combo_pdf_run_3.maff)\n[plot_input_fields_rtp3_thlp3_1.maff](https://github.com/larson-group/trac_attachment_archive/blob/master/trac_test/822/plot_input_fields_rtp3_thlp3_1.maff)\n[plot_new_pdf_20180522_test_1.maff](https://github.com/larson-group/trac_attachment_archive/blob/master/trac_test/822/plot_new_pdf_20180522_test_1.maff)\n[plot_attempts_8_10.maff](https://github.com/larson-group/trac_attachment_archive/blob/master/trac_test/822/plot_attempts_8_10.maff)\n[plot_attempt_8_only.maff](https://github.com/larson-group/trac_attachment_archive/blob/master/trac_test/822/plot_attempt_8_only.maff)\n[plot_beta_1p3.maff](https://github.com/larson-group/trac_attachment_archive/blob/master/trac_test/822/plot_beta_1p3.maff)\n[plot_beta_1p3_all.maff](https://github.com/larson-group/trac_attachment_archive/blob/master/trac_test/822/plot_beta_1p3_all.maff)\n\nMigrated from http://carson.math.uwm.edu/trac/clubb/ticket/319\n```json\n{\n    \"status\": \"closed\", \n    \"changetime\": \"2010-11-22T18:42:59\", \n    \"description\": \"CLUBB has several Cu benchmark cases: BOMEX, RICO, and LBA.  In the past, when we've run these case with small timestep (e.g. 1 s), the cloud fraction has been much too large (e.g. 1 instead of 0.1).  \\n\\nMore recently, I have found that RICO has too much cloud fraction if the timestep is 1 s but the grid has 128 levels.  However, if the grid spacing is reduced to 40 m, then it works again.\\n\\nWe should re-check whether or not this is still a problem.\\n\\nWhile we're at it, for thoroughness, let's check all benchmark CLUBB cases.\", \n    \"reporter\": \"vlarson@uwm.edu\", \n    \"cc\": \"vlarson@uwm.edu\", \n    \"resolution\": \"Verified by V. Larson\", \n    \"_ts\": \"1290451379000000\", \n    \"component\": \"clubb_src\", \n    \"summary\": \"Check accuracy of SCM simulations at small timestep\", \n    \"priority\": \"minor\", \n    \"keywords\": \"\", \n    \"time\": \"2010-04-10T23:25:32\", \n    \"milestone\": \"\", \n    \"owner\": \"meyern@uwm.edu\", \n    \"type\": \"defect\"\n}\n```\n"},"comment":{"url":"https://api.github.com/repos/StrikeNP/trac_test/issues/comments/399474924","html_url":"https://github.com/StrikeNP/trac_test/issues/319#issuecomment-399474924","issue_url":"https://api.github.com/repos/StrikeNP/trac_test/issues/319","id":399474924,"node_id":"MDEyOklzc3VlQ29tbWVudDM5OTQ3NDkyNA==","user":{"login":"StrikeNP","id":2577059,"node_id":"MDQ6VXNlcjI1NzcwNTk=","avatar_url":"https://avatars0.githubusercontent.com/u/2577059?v=4","gravatar_id":"","url":"https://api.github.com/users/StrikeNP","html_url":"https://github.com/StrikeNP","followers_url":"https://api.github.com/users/StrikeNP/followers","following_url":"https://api.github.com/users/StrikeNP/following{/other_user}","gists_url":"https://api.github.com/users/StrikeNP/gists{/gist_id}","starred_url":"https://api.github.com/users/StrikeNP/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/StrikeNP/subscriptions","organizations_url":"https://api.github.com/users/StrikeNP/orgs","repos_url":"https://api.github.com/users/StrikeNP/repos","events_url":"https://api.github.com/users/StrikeNP/events{/privacy}","received_events_url":"https://api.github.com/users/StrikeNP/received_events","type":"User","site_admin":false},"created_at":"2018-06-22T15:08:39Z","updated_at":"2018-06-22T15:08:39Z","author_association":"OWNER","body":"**Trac update on 2010/10/18 at 17:25**\n**meyern@uwm.edu commented:**\n\nI'm a little concerned because these cases haven't finished running yet.  I had to rerun the following: dycoms2_rf02_so, arm_97, astex_a209, all the cloud_feedback cases, lba, rico_LH and twp_ice.  Of these, dycoms, astex and cloud_feedback_s6 have finished and s6_p2k is still running.  There was an error in arm_97 as follows: \nSTOP STOP in sounding\n STOP Not enough sounding data to initialize grid:\n  highest sounding level27500.0\n  should be higher than highest thermodynamic point27610.0\nI know it was running cloud_feeback_s6 when I left on Thursday, so it appears to have taken 3.5 days to run (almost) 2 cases.  Does this seem reasonable?\nI terminated this run accidentally (I think), presumably when I was copying and pasting names to put in this entry.  I've restarted the other cases that haven't finished and fixed the error from arm_97.\n\nI'll put up a plotgen of the completed cases shortly.\n\n"}}
{"actor":{"display_login":"StrikeNP"}}