{"action":"created","issue":{"url":"https://api.github.com/repos/wmwolf/MesaScript/issues/2","repository_url":"https://api.github.com/repos/wmwolf/MesaScript","labels_url":"https://api.github.com/repos/wmwolf/MesaScript/issues/2/labels{/name}","comments_url":"https://api.github.com/repos/wmwolf/MesaScript/issues/2/comments","events_url":"https://api.github.com/repos/wmwolf/MesaScript/issues/2/events","html_url":"https://github.com/wmwolf/MesaScript/issues/2","id":188676634,"number":2,"title":"Binary Support?","user":{"login":"branbauep","id":18405113,"avatar_url":"https://avatars.githubusercontent.com/u/18405113?v=3","gravatar_id":"","url":"https://api.github.com/users/branbauep","html_url":"https://github.com/branbauep","followers_url":"https://api.github.com/users/branbauep/followers","following_url":"https://api.github.com/users/branbauep/following{/other_user}","gists_url":"https://api.github.com/users/branbauep/gists{/gist_id}","starred_url":"https://api.github.com/users/branbauep/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/branbauep/subscriptions","organizations_url":"https://api.github.com/users/branbauep/orgs","repos_url":"https://api.github.com/users/branbauep/repos","events_url":"https://api.github.com/users/branbauep/events{/privacy}","received_events_url":"https://api.github.com/users/branbauep/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-11-11T03:24:44Z","updated_at":"2016-11-11T03:45:49Z","closed_at":null,"body":"binary_job and binary_project inlist options don't appear to be supported currently. How hard would that be to add?"},"comment":{"url":"https://api.github.com/repos/wmwolf/MesaScript/issues/comments/259874319","html_url":"https://github.com/wmwolf/MesaScript/issues/2#issuecomment-259874319","issue_url":"https://api.github.com/repos/wmwolf/MesaScript/issues/2","id":259874319,"user":{"login":"wmwolf","id":706243,"avatar_url":"https://avatars.githubusercontent.com/u/706243?v=3","gravatar_id":"","url":"https://api.github.com/users/wmwolf","html_url":"https://github.com/wmwolf","followers_url":"https://api.github.com/users/wmwolf/followers","following_url":"https://api.github.com/users/wmwolf/following{/other_user}","gists_url":"https://api.github.com/users/wmwolf/gists{/gist_id}","starred_url":"https://api.github.com/users/wmwolf/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wmwolf/subscriptions","organizations_url":"https://api.github.com/users/wmwolf/orgs","repos_url":"https://api.github.com/users/wmwolf/repos","events_url":"https://api.github.com/users/wmwolf/events{/privacy}","received_events_url":"https://api.github.com/users/wmwolf/received_events","type":"User","site_admin":false},"created_at":"2016-11-11T03:45:49Z","updated_at":"2016-11-11T03:45:49Z","body":"So long as their aren’t any name collisions between the binary and star namelist commands, it should be extremely easy. If there are name collisions... I don't actually know what would happen. It would be bad, though, and the code can't handle that. By name collision, I mean commands in two different namelists with the same name.\r\n\r\nIf you look in the mesa_script.rb file (mesa_script/lib/mesa_script.rb in the repo), lines 23-46 might be of interest:\r\n\r\n```ruby\r\n# Different namelists can be added or subtracted if MESA should change or\r\n# proprietary inlists are required. Later hashes should be edited in a\r\n# similar way to get the desired behavior for additional namelists.\r\n\r\n#################### ADD NEW NAMELISTS HERE ####################\r\n@namelists = %w{ star_job controls pgstar }\r\n################## POINT TO .INC FILES HERE ####################\r\n@nt_files = {\r\n              'star_job' => %w{star_job_controls.inc},\r\n              'controls' => %w{star_controls.inc},\r\n              'pgstar'   => %w{pgstar_controls.inc},\r\n            }\r\n@nt_files['controls'] << \"ctrls_io.#{f_end}\"\r\n# User can specify a custom name for a namelist defaults file. The default\r\n# is simply the namelist name followed by '.defaults'\r\n\r\n################ POINT TO .DEFAULTS FILES HERE #################\r\n@d_files = {}\r\n\r\n# User can add new paths to namelist default files through this hash\r\n\r\n############ GIVE PATHS TO .INC AND .DEF FILES HERE ###########\r\n@nt_paths = Hash.new(ENV['MESA_DIR'] + '/star/private/')\r\n@d_paths = Hash.new(ENV['MESA_DIR'] + '/star/defaults/')\r\n```\r\n\r\nThe naming conventions I chose are a bit opaque, but you can add new namelists (like binary_job and binary_project) to the `@namelists` array and then add a new entry in the `@nt_files` and `@nt_paths` objects to point to where the actual namelist objects are declared in fortran (I don’t remember what nt means… sorry about that, but the standard star namelists should give you an idea of what we need).\r\n\r\nFinally we'd need to point `@d_paths` and `@d_files` to the proper defaults folders and files, respectively. This would probably mean something like\r\n\r\n`@d_paths['binary_job'] = File.join(ENV['MESA_DIR'], 'binary', 'defaults')`\r\n\r\nand much the same for `'binary_project'`. The default value for the default file name should be sufficient (simply the namelist name followed up with `'.defaults'`.\r\n\r\nIf all of that is set up, the binary namelists should work like the others, but I have never actually tested this. `binary` was in a state of upheaval when I wrote MesaScript, and due to its surprising robustness, I haven't had to edit much of MesaScript's innards since its original release. \r\n\r\nAt some point I'd prefer to outsource this stuff to a config file so you don't have to muck around with the code, but this is the first time someone has asked about adding additional namelists.\r\n"}}
{"actor":{"display_login":"wmwolf"}}