#148 Improve functionality of the config parsing

[rmjarvis]

There are now configuration files (both yaml and json) that build the same files as those built by 8 current demo scripts. These are in examples/*.yaml and examples/json/*.json. (I think it's fair to say that yaml is our preferred format, hence the json files being relegated to a subdirectory.)

There are two executable scripts in the examples directory called check_yaml and check_json, which run both the Demo.py files and also the versions that parse the .yaml or .json config files (respectively) and compare their outputs. The scripts aren't very sophisticated, but if the last line of output is

Checking diffs: (No output means success)

then everything is working correctly.

There is also fairly complete documentation on the wiki, which could be considered part of the pull request, even though it won't show up in the diff.

The branch to be merged is #148, but other issues that could likely be closed after this is merged are:

• Unit tests to ensure that the object_param_dict is kept updated #153 We got rid of the object_param_dict, so we don't need unit tests to keep it updated. (And there are now unit tests for the new way of doing the config stuff.)
• parameter-based GSObject classes #195 We realized this was not necessary, and it seemed too unwieldy and difficult to manage to be worth keeping. Rolled back in Partial rollback of #195 to provide introspectable descriptors only #234.
• suggest making Angle immutable in Python #219 Making Angle immutable may still be a good idea, but it's not as important now. At least the specific concerns put forward in that issue aren't relevant anymore.
• shears (and other compound parameters) in configs #220 The concerns about shears in config files that were raised there aren't relevant anymore.
• Partial rollback of #195 to provide introspectable descriptors only #234 The branch for Partial rollback of #195 to provide introspectable descriptors only #234 was merged into this branch, so it is effectively included in this pull request.

[barnabytprowe]

That's fine, lam_over_diam is good. Sorry for missing that query (I'd
noticed the question but didn't succeed in getting back to it).

On Fri, Sep 7, 2012 at 6:18 AM, Mike Jarvis notifications@github.comwrote:

lam_over_D (for Airy and OpticalPSF) is the only parameter that isn't pure
lowercase. It seems like we might want to change that. Suggestions:
lam_over_diam, size, rayleigh_size, resolution, tel_resolution...

Since no one weighed in on this point, I'm going to go with lam_over_diam,
unless there are any objections.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/241#issuecomment-8356296.

Barnaby Rowe
Postdoctoral Research Associate

Department of Physics & Astronomy
University College London
Gower Street
London WC1E 6BT
United Kingdom

[rmandelb]

Yes, sorry I missed that query. I'm fine with whatever you want to do for lam_over_D.

At this point, I think that this is quite a useful expansion of the config system, and a really amazing set of examples, thank you Mike! I would be fine with merging whenever. I suggest the following schedule -

• merge this after another ~day for comments (will @TallJimbo want a chance to comment? Jim, if you do, then please let us know that we should wait for you!)
• give over the weekend for the INSTALL file pull request #235 - Re-jigged INSTALL file #239, and merge Monday morning
• aim to merge in the lensing engine at the end of Monday if possible - I realize that's a rather tight schedule!
• Monday night or Tuesday I will quickly take care of revisit repository organization and make a road map #214. That should be very quickly mergeable as it's just a rearrangement, no actual code.
• Once revisit repository organization and make a road map #214 is done, @rmjarvis can make the lensing engine work with config (~1 week timescale?)

And then I think we can focus on the remaining issues for releasing the code within GREAT3, namely the documentation drive (we have 5 volunteers to go over the galsim/ python docstrings) and installation procedures.

It's coming together...
(sorry for getting slightly off-topic on the pull request!)

[rmjarvis]

I think I addressed all comments and suggested changes. So I'm fine with merging whenever, but also happy to wait for more people to have a chance to comment.

[barnabytprowe]

OK, so I think we're still all good to merge here? I'll leave it until mid-morning EDT to see if there are any objections, then will merge... But it's OK to wait longer if people want more time, so please just let us know.

Thanks for all the work on this branch everybody, particularly Mike.

[rmandelb]

Yes, I think we're fine to merge.

[rmandelb]

(and once we do, I will make a pull request for 214, which i branched off of this branch)

[rmandelb]

Barney, if you're merging, will you also take care of the list (in the 1st message on the pull request) of issues that are to be closed / modified because of this one? (153, etc.)

[barnabytprowe]

Will do!

Barnaby Rowe
Postdoctoral Research Associate

Department of Physics & Astronomy
University College London
Gower Street
London WC1E 6BT
United Kingdom

On 10 Sep 2012, at 14:59, rmandelb wrote:

Barney, if you're merging, will you also take care of the list (in the 1st message on the pull request) of issues that are to be closed / modified because of this one? (153, etc.)

—
Reply to this email directly or view it on GitHub.

[barnabytprowe]

OK, I think I've closed all the related issues... Did one last compilation and scons tests run, all ok. Here goes with the merge!