{"action":"created","issue":{"url":"https://api.github.com/repos/StrikeNP/trac_test/issues/677","repository_url":"https://api.github.com/repos/StrikeNP/trac_test","labels_url":"https://api.github.com/repos/StrikeNP/trac_test/issues/677/labels{/name}","comments_url":"https://api.github.com/repos/StrikeNP/trac_test/issues/677/comments","events_url":"https://api.github.com/repos/StrikeNP/trac_test/issues/677/events","html_url":"https://github.com/StrikeNP/trac_test/issues/677","id":334662527,"node_id":"MDU6SXNzdWUzMzQ2NjI1Mjc=","number":677,"title":"Reconstruct wm_zt inside of the subroutine setup_pdf_parameters (Trac #677)","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":971576851,"node_id":"MDU6TGFiZWw5NzE1NzY4NTE=","url":"https://api.github.com/repos/StrikeNP/trac_test/labels/enhancement","name":"enhancement","color":"a2eeef","default":true},{"id":971649570,"node_id":"MDU6TGFiZWw5NzE2NDk1NzA=","url":"https://api.github.com/repos/StrikeNP/trac_test/labels/raut@uwm.edu","name":"raut@uwm.edu","color":"FFFFFF","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/StrikeNP/trac_test/milestones/4","html_url":"https://github.com/StrikeNP/trac_test/milestone/4","labels_url":"https://api.github.com/repos/StrikeNP/trac_test/milestones/4/labels","id":3442833,"node_id":"MDk6TWlsZXN0b25lMzQ0MjgzMw==","number":4,"title":"3. Refactor CLUBB","description":null,"creator":{"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},"open_issues":37,"closed_issues":107,"state":"open","created_at":"2018-06-21T18:01:51Z","updated_at":"2018-06-23T18:46:26Z","due_on":null,"closed_at":null},"comments":4,"created_at":"2018-06-21T21:21:40Z","updated_at":"2018-06-23T18:46:47Z","closed_at":null,"author_association":"OWNER","body":"**Introduction**\n\nIn the subroutine `setup_pdf_parameters`, a variable, `wm_zt` was added to the argument list. Since `pdf_params` is already in the argument list, we could simply reconstruct `wm_zt` from it. It would avoid having to pass an additional parameter, and it would reduce fears that the two are inconsistent.\n\n**Tests**\n\nOutput should be bin-diff identical up to round-off.\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/677\n```json\n{\n    \"status\": \"closed\", \n    \"changetime\": \"2014-04-19T20:39:41\", \n    \"description\": \"'''Introduction'''\\n\\nIn the subroutine `setup_pdf_parameters`, a variable, `wm_zt` was added to the argument list. Since `pdf_params` is already in the argument list, we could simply reconstruct `wm_zt` from it. It would avoid having to pass an additional parameter, and it would reduce fears that the two are inconsistent.\\n\\n'''Tests'''\\n\\nOutput should be bin-diff identical up to round-off.\", \n    \"reporter\": \"raut@uwm.edu\", \n    \"cc\": \"vlarson@uwm.edu\", \n    \"resolution\": \"fixed\", \n    \"_ts\": \"1397939981972486\", \n    \"component\": \"clubb_src\", \n    \"summary\": \"Reconstruct wm_zt inside of the subroutine setup_pdf_parameters\", \n    \"priority\": \"major\", \n    \"keywords\": \"\", \n    \"time\": \"2014-04-18T22:18:42\", \n    \"milestone\": \"3. Refactor CLUBB\", \n    \"owner\": \"raut@uwm.edu\", \n    \"type\": \"enhancement\"\n}\n```\n"},"comment":{"url":"https://api.github.com/repos/StrikeNP/trac_test/issues/comments/399700427","html_url":"https://github.com/StrikeNP/trac_test/issues/677#issuecomment-399700427","issue_url":"https://api.github.com/repos/StrikeNP/trac_test/issues/677","id":399700427,"node_id":"MDEyOklzc3VlQ29tbWVudDM5OTcwMDQyNw==","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-23T18:46:47Z","updated_at":"2018-06-23T18:46:47Z","author_association":"OWNER","body":"**Trac update on 2014/04/19 at 04:22**\n\n* bmg2@uwm.edu changed _comment0 from:\n\n> I'm sorry, but I have to say that I disagree with these coding proposals.\n> \n> In the past, we have gone through great measures to reduce the numerical expense of CLUBB, especially in regards to the portions of CLUBB that are called as part of a host model.  Additional mathematical operations, such as these, require additional numerical expense.  Since {{{setup_pdf_parameters}}} is called from every column of a host model, this increase is magnified.\n> \n> In {{{pdf_closure}}}, {{{w1}}} and {{{w2}}} are found from {{{wm_zt}}}, so there should be no discrepancy.  The variable {{{wm_zt}}} is never reset in CLUBB, and {{{w1}}} and {{{w2}}} are only calculated at one point in the code every timestep.  They will not be inconsistent.  Additionally, in the same subroutine, {{{rcm}}} and {{{cloud_frac}}} are already calculated from {{{rc1}}} and {{{rc2}}}, and {{{cloud_frac1}}} and {{{cloud_frac2}}}, respectively.  These calculations will not be inconsistent.  Recalculating these mean fields would be an unnecessary waste of computer time.  Shall we also recalculate {{{rcm}}} and {{{cloud_frac}}} in every microphysics scheme that uses them as input?\n> \n> I guess I don't see enough benefit to this to offset the negatives of it, which would be additional unnecessary numerical expense in a host model and additional confusion (users will think \"why are these fields being calculated again?  There must have been some change in model fields to warrant recalculation\" -- which is not the case).  I would say that reducing the subroutine call lists by a couple variables most definitely is not worth these negatives.\n\nto:\n\n> 1397881571720126\n\n\n* bmg2@uwm.edu changed _comment1 from:\n\n> I'm sorry, but I have to say that I disagree with these coding proposals.\n> \n> In the past, we have gone through great measures to reduce the numerical expense of CLUBB (for example, defining {{{invrs_rho_ds_zt}}} so we don't have the extra division operation of {{{one/rho_ds}}} every time it is necessary, etc.), especially in regards to the portions of CLUBB that are called as part of a host model.  Additional mathematical operations, such as these, require additional numerical expense.  Since {{{setup_pdf_parameters}}} is called from every column of a host model, this increase is magnified.\n> \n> In {{{pdf_closure}}}, {{{w1}}} and {{{w2}}} are found from {{{wm_zt}}}, so there should be no discrepancy.  The variable {{{wm_zt}}} is never reset in CLUBB, and {{{w1}}} and {{{w2}}} are only calculated at one point in the code every timestep.  They will not be inconsistent.  Additionally, in the same subroutine, {{{rcm}}} and {{{cloud_frac}}} are already calculated from {{{rc1}}} and {{{rc2}}}, and {{{cloud_frac1}}} and {{{cloud_frac2}}}, respectively.  These calculations will not be inconsistent.  Recalculating these mean fields would be an unnecessary waste of computer time.  Shall we also recalculate {{{rcm}}} and {{{cloud_frac}}} in every microphysics scheme that uses them as input?\n> \n> I guess I don't see enough benefit to this to offset the negatives of it, which would be additional unnecessary numerical expense in a host model and additional confusion (users will think \"why are these fields being calculated again?  There must have been some change in model fields to warrant recalculation\" -- which is not the case).  I would say that reducing the subroutine call lists by a couple variables most definitely is not worth these negatives.\n\nto:\n\n> 1397881604815102\n\n\n* bmg2@uwm.edu changed _comment2 from:\n\n> I'm sorry, but I have to say that I disagree with these coding proposals.\n> \n> In the past, we have gone through great measures to reduce the numerical expense of CLUBB (for example, defining {{{invrs_rho_ds_zt}}} so we don't have the extra division operation of {{{one/rho_ds_zt}}} every time it is necessary, etc.), especially in regards to the portions of CLUBB that are called as part of a host model.  Additional mathematical operations, such as these, require additional numerical expense.  Since {{{setup_pdf_parameters}}} is called from every column of a host model, this increase is magnified.\n> \n> In {{{pdf_closure}}}, {{{w1}}} and {{{w2}}} are found from {{{wm_zt}}}, so there should be no discrepancy.  The variable {{{wm_zt}}} is never reset in CLUBB, and {{{w1}}} and {{{w2}}} are only calculated at one point in the code every timestep.  They will not be inconsistent.  Additionally, in the same subroutine, {{{rcm}}} and {{{cloud_frac}}} are already calculated from {{{rc1}}} and {{{rc2}}}, and {{{cloud_frac1}}} and {{{cloud_frac2}}}, respectively.  These calculations will not be inconsistent.  Recalculating these mean fields would be an unnecessary waste of computer time.  Shall we also recalculate {{{rcm}}} and {{{cloud_frac}}} in every microphysics scheme that uses them as input?\n> \n> I guess I don't see enough benefit to this to offset the negatives of it, which would be additional unnecessary numerical expense in a host model and additional confusion (users will think \"why are these fields being calculated again?  There must have been some change in model fields to warrant recalculation\" -- which is not the case).  I would say that reducing the subroutine call lists by a couple variables most definitely is not worth these negatives.\n\nto:\n\n> 1397881725678291\n\n\n* bmg2@uwm.edu changed _comment3 from:\n\n> I'm sorry, but I have to say that I disagree with these coding proposals.\n> \n> In the past, we have gone through great measures to reduce the numerical expense of CLUBB (for example, defining {{{invrs_rho_ds_zt}}} so we don't have the extra division operation of {{{one/rho_ds_zt}}} every time it is necessary, etc.), especially in regards to the portions of CLUBB that are called as part of a host model.  Additional mathematical operations, such as these, require additional numerical expense.  Since {{{setup_pdf_parameters}}} is called from every column of a host model, this increase is magnified.\n> \n> In {{{pdf_closure}}}, {{{w1}}} and {{{w2}}} are found from {{{wm_zt}}}, so there should be no discrepancy.  The variable {{{wm_zt}}} is never reset in CLUBB, and {{{w1}}} and {{{w2}}} are only calculated at one point in the code every timestep.  They will not be inconsistent.  Additionally, in the same subroutine, {{{rcm}}} and {{{cloud_frac}}} are already calculated from {{{rc1}}} and {{{rc2}}}, and {{{cloud_frac1}}} and {{{cloud_frac2}}}, respectively.  These calculations will not be inconsistent.  Recalculating these mean fields would be an unnecessary waste of computer time.  Should we also recalculate {{{rcm}}} and {{{cloud_frac}}} in every microphysics scheme that uses them as input?\n> \n> I guess I don't see enough benefit to this to offset the negatives of it, which would be additional unnecessary numerical expense in a host model and additional confusion (users will think \"why are these fields being calculated again?  There must have been some change in model fields to warrant recalculation\" -- which is not the case).  I would say that reducing the subroutine call lists by a couple variables most definitely is not worth these negatives.\n\nto:\n\n> 1397884212193534\n\n\n* bmg2@uwm.edu changed _comment4 from:\n\n> I'm sorry, but I have to say that I disagree with these coding proposals.\n> \n> In the past, we have gone through great measures to reduce the numerical expense of CLUBB (for example, defining {{{invrs_rho_ds_zt}}} so we don't have the extra division operation of {{{one/rho_ds_zt}}} every time it is necessary, etc.), especially in regards to the portions of CLUBB that are called as part of a host model.  Additional mathematical operations, such as these, require additional numerical expense.  Since {{{setup_pdf_parameters}}} is called from every column of a host model, this increase is magnified.\n> \n> In {{{pdf_closure}}}, {{{w1}}} and {{{w2}}} are found from {{{wm_zt}}}, so there should be no discrepancy.  The variable {{{wm_zt}}} is never reset in CLUBB, and {{{w1}}} and {{{w2}}} are only calculated at one point in the code every timestep.  They will not be inconsistent.  Additionally, in the same subroutine, {{{rcm}}} and {{{cloud_frac}}} are already calculated from {{{rc1}}} and {{{rc2}}}, and {{{cloud_frac1}}} and {{{cloud_frac2}}}, respectively.  These calculations will not be inconsistent.  Recalculating these mean fields would be an unnecessary waste of computer time.  Should we also recalculate {{{rcm}}} and {{{cloud_frac}}} in every microphysics scheme that uses them as input, and recalculate {{{wm_zt}}} in every {{{advance_#####}}} subroutine that uses it as input, as well?\n> \n> I guess I don't see enough benefit to this to offset the negatives of it, which would be additional unnecessary numerical expense in a host model and additional confusion (users will think \"why are these fields being calculated again?  There must have been some change in model fields to warrant recalculation\" -- which is not the case).  I would say that reducing the subroutine call lists by a couple variables most definitely is not worth these negatives.\n\nto:\n\n> 1397884230817465\n\n\n* bmg2@uwm.edu changed _comment5 from:\n\n> I'm sorry, but I have to say that I disagree with these coding proposals.\n> \n> In the past, we have gone through great measures to reduce the numerical expense of CLUBB (for example, defining {{{invrs_rho_ds_zt}}} so we don't have the extra division operation of {{{one/rho_ds_zt}}} every time it is necessary, etc.), especially in regards to the portions of CLUBB that are called as part of a host model.  Additional mathematical operations, such as these, require additional numerical expense.  Since {{{setup_pdf_parameters}}} is called from every column of a host model, this increase is magnified.\n> \n> In {{{pdf_closure}}}, {{{w1}}} and {{{w2}}} are found from {{{wm_zt}}}, so there should be no discrepancy.  The variable {{{wm_zt}}} is never reset in CLUBB, and {{{w1}}} and {{{w2}}} are only calculated at one point in the code every timestep.  They will not be inconsistent.  Additionally, in the same subroutine, {{{rcm}}} and {{{cloud_frac}}} are already calculated from {{{rc1}}} and {{{rc2}}}, and {{{cloud_frac1}}} and {{{cloud_frac2}}}, respectively.  These calculations will not be inconsistent.  Recalculating these mean fields would be an unnecessary waste of computer time.  Should we recalculate {{{rcm}}} and {{{cloud_frac}}} in every microphysics scheme that uses them as input, and recalculate {{{wm_zt}}} in every {{{advance_#####}}} subroutine that uses it as input, as well?\n> \n> I guess I don't see enough benefit to this to offset the negatives of it, which would be additional unnecessary numerical expense in a host model and additional confusion (users will think \"why are these fields being calculated again?  There must have been some change in model fields to warrant recalculation\" -- which is not the case).  I would say that reducing the subroutine call lists by a couple variables most definitely is not worth these negatives.\n\nto:\n\n> 1397887867931685\n\n\n* bmg2@uwm.edu changed _comment6 from:\n\n> I'm sorry, but I have to say that I disagree with these coding proposals.\n> \n> In the past, we have gone through great measures to reduce the numerical expense of CLUBB (for example, defining {{{invrs_rho_ds_zt}}} so we don't have the extra division operation of {{{one/rho_ds_zt}}} every time it is necessary, etc.), especially in regards to the portions of CLUBB that are called as part of a host model.  Additional mathematical operations, such as the ones that were added in r6846, require additional numerical expense.  Since {{{setup_pdf_parameters}}} is called from every column of a host model, this increase is magnified.\n> \n> In {{{pdf_closure}}}, {{{w1}}} and {{{w2}}} are found from {{{wm_zt}}}, so there should be no discrepancy.  The variable {{{wm_zt}}} is never reset in CLUBB, and {{{w1}}} and {{{w2}}} are only calculated at one point in the code every timestep.  They will not be inconsistent.  Additionally, in the same subroutine, {{{rcm}}} and {{{cloud_frac}}} are already calculated from {{{rc1}}} and {{{rc2}}}, and {{{cloud_frac1}}} and {{{cloud_frac2}}}, respectively.  These calculations will not be inconsistent.  Recalculating these mean fields would be an unnecessary waste of computer time.  Should we recalculate {{{rcm}}} and {{{cloud_frac}}} in every microphysics scheme that uses them as input, and recalculate {{{wm_zt}}} in every {{{advance_#####}}} subroutine that uses it as input, as well?\n> \n> I guess I don't see enough benefit to this to offset the negatives of it, which would be additional unnecessary numerical expense in a host model and additional confusion (users will think \"why are these fields being calculated again?  There must have been some change in model fields to warrant recalculation\" -- which is not the case).  I would say that reducing the subroutine call lists by a couple variables most definitely is not worth these negatives.\n\nto:\n\n> 1397887982059387\n\n\n* **bmg2@uwm.edu commented:**\n\nI'm sorry, but I have to say that I disagree with these coding proposals.\n\nIn the past, we have gone through great measures to reduce the numerical expense of CLUBB (for example, defining ```invrs_rho_ds_zt``` so we don't have the extra division operation of ```one/rho_ds_zt``` every time it is necessary, etc.), especially in regards to the portions of CLUBB that are called as part of a host model.  Additional mathematical operations, such as the ones that were added in r6846 and proposed in comment:4, require additional numerical expense.  Since ```setup_pdf_parameters``` is called from every column of a host model, this increase is magnified.\n\nIn ```pdf_closure```, ```w1``` and ```w2``` are found from ```wm_zt```, so there should be no discrepancy.  The variable ```wm_zt``` is never reset in CLUBB, and ```w1``` and ```w2``` are only calculated at one point in the code every timestep.  They will not be inconsistent.  Additionally, in the same subroutine, ```rcm``` and ```cloud_frac``` are already calculated from ```rc1``` and ```rc2```, and ```cloud_frac1``` and ```cloud_frac2```, respectively.  These calculations will not be inconsistent.  Recalculating these mean fields would be an unnecessary waste of computer time.  Should we recalculate ```rcm``` and ```cloud_frac``` in every microphysics scheme that uses them as input, and recalculate ```wm_zt``` in every ```advance_#####``` subroutine that uses it as input, as well?\n\nI guess I don't see enough benefit to this to offset the negatives of it, which would be additional unnecessary numerical expense in a host model and additional confusion (users will think \"why are these fields being calculated again?  There must have been some change in model fields to warrant recalculation\" -- which is not the case).  I would say that reducing the subroutine call lists by a couple variables most definitely is not worth these negatives.\n\n"}}
{"actor":{"display_login":"StrikeNP"}}