search

philrosenfield / match

Python utilities for processing and plotting input and output from Andy Dolphin's MATCH
MIT License
4 stars 1 forks source link

Usage Examples #3

Open dweisz opened 8 years ago

dweisz commented 8 years ago

Given the growing diversity of code, I think we need to provide more examples (e.g., input files, plots) of how to use the code and what to expect as correct output. It would probably be better do this on a folder-by-folder basis? Let's iterate on this.

philrosenfield commented 8 years ago

That's a great idea. I know the scripts I've written semi-automate the match parameter file making process as well as check parameter boundaries before and after a calcsfh run, I'll write up some examples when I get a chance.

bd-j commented 8 years ago

yeah, coming at this as not really a match user, it’s tough to decipher even the general purpose of much of the code.

E.g. I have dead-simple but potentially relevant code that reads zcombine output into a numpy structured array for the SFH, and I can’t tell if that’s duplicating something already here - it must be, right?

directory level readmes that just give an idea of what is being accomplished would be very helpful. Not sure if it’s worth thinking about organizing things into categories... file io, driver script generation, plotting cmd’s, plotting SFHs, etc.

On Oct 8, 2015, at 3:43 PM, Phil Rosenfield notifications@github.com wrote:

That's a great idea. I know the scripts I've written semi-automate the match parameter file making process as well as check parameter boundaries before and after a calcsfh run, I'll write up some examples when I get a chance.

— Reply to this email directly or view it on GitHub https://github.com/dweisz/match/issues/3#issuecomment-146666461.

philrosenfield commented 8 years ago

The least I could do -- I added a readme.md to the scripts directory.

Perhaps we can have a data folder with example photometry and fake file and write an ipython notebook for each subfolder that uses that data. It could serve as a bit of a tutorial too.

dweisz commented 8 years ago

Ultimately, I think that ipython notebooks are going to be the way to go. But, before we can make those, it would be good to see what all of the current code does, so we can eliminate redundancies and streamline.

I'm thinking that in the long run, it would be good to have a set of scripts for common actions (e.g., making parameter files, plotting Hess diagrams, plotting CMDs and ASTs). Then, we could make folders for each type of science (e.g., SFH, SSPs, IMF, dust, etc) that call the common functions for file i/o, but are otherwise driven by the particular science theme.

dweisz commented 8 years ago

Also, when I'm visiting CfA next week, it might be a good use of an hour to map a potential structure out on a whiteboard.

philrosenfield commented 7 years ago

Also needed: An interface for each examples. I don't think gh-pages can be private, so I or someone may need to privately host something.

mfouesneau commented 7 years ago

why not simply notebooks for now? you can show it from github directly and at some point make html files if you want to publish them in that way.

philrosenfield commented 7 years ago

I didn't mean to shift away from notebooks. I was thinking more of a readme file for the directory with a table of contents. You can't interact with notebooks in github, but students would be able to do that in their cloned/forked repos.