This looks great to me. It's a good mix of what we can do now, what we want to do in the future, and the manner in which we'll get there. +1<br><br><div class="gmail_quote">On Fri, Jun 17, 2011 at 3:20 PM, j s oishi <span dir="ltr"><<a href="mailto:jsoishi@gmail.com">jsoishi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">This is looking awesome. Let me add a tiny bit of refinement:<br>
<br>
Draft 3<br>
--------<br>
<div class="im">The yt project aims to produce an integrated science environment<br>
for collaboratively asking and answering astrophysical<br>
</div>questions. To do so, it will encompass the creation of initial<br>
<div class="im">conditions, the execution of simulations, and the detailed<br>
exploration and visualization of the resultant data. It will<br>
</div>also provide a standard framework based on physical quantities<br>
<div><div></div><div class="h5">for interoperability between codes.<br>
<br>
Development of yt is driven by a commitment to Open Science<br>
principles as manifested in participatory development,<br>
reproducibility, documented and approachable code, a friendly and<br>
helpful community of users and developers, and Free and Libre<br>
Open Source Software.<br>
<br>
<br>
> The yt project aims to produce an integrated science environment for<br>
> collaboratively asking and answering astrophysical questions, encompassing<br>
> the creation of initial conditions, the execution of simulations and the<br>
> detailed exploration and visualization of the resultant data. It will<br>
> provide a standard framework based on physical quantities for<br>
> interoperability<br>
> between codes. Development of yt is driven by a commitment to Open Science<br>
> principles<br>
> as manifested in participatory development, reproducibility, documented and<br>
> approachable code, a friendly and helpful community of users and developers,<br>
> and Free and Libre Open Source Software.<br>
><br>
><br>
><br>
> On 6/14/11 1:02 AM, Matthew Turk wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> tl;dr summary: New bullet points below, along with a first draft at a<br>
>> proper prose solidification. More comments still requested.<br>
>><br>
>> Thanks everyone for your thoughtful responses. Having this discussion<br>
>> as a group is really the only way to have the outcome of it be<br>
>> meaningful; I'm glad we could have as much of a discussion as we<br>
>> already have, and I hope that moving forward we can keep talking about<br>
>> this and refining it to sort of steer ourselves.<br>
>><br>
>> In reading over your replies, it's become clear that the mission goal<br>
>> bullet points in that original list were a bit ... well, shall we say,<br>
>> under-ambitious? So let's take the gloves off a bit. Chris, your<br>
>> comments in particular made me realize that my own feelings about this<br>
>> project we've got going are a bit more ambitious; Brian, Britton and<br>
>> Jeff, yours did as well. And this didn't come through in the bullet<br>
>> points, although it was alluded to. I'll put my comments at the<br>
>> bottom, along with an updated list of bullet points, after I respond<br>
>> to a couple things that were brought up.<br>
>><br>
>> On Mon, Jun 13, 2011 at 5:06 PM, j s oishi<<a href="mailto:jsoishi@gmail.com">jsoishi@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi all,<br>
>>><br>
>>> This is already a great discussion, and it seems to me that there are<br>
>>> a lot of great ideas that I only want to echo. First, I think what<br>
>>> Matt started with is a great foundation: yt should continue to be a<br>
>>> collaborative, open-source tool for reproducible physical analysis of<br>
>>> simulation data. I think the idea that not only is yt itself open<br>
>>> source, but the *entire software stack upon which it rests* is also<br>
>>> open source is a point worth emphasizing. If nothing else, a user gets<br>
>>> not only yt but also an amazing toolkit for doing numerical<br>
>>> computation free of cost and restrictive licenses.<br>
>><br>
>> That is a very, very good point -- and the impetus for its initial<br>
>> creation, actually.<br>
>><br>
>>> Second, I think that Brian's point about data provenance and<br>
>>> reproducibility of an entire project is really a direction I would<br>
>>> love to see yt move in. yt should allow (and encourage!)<br>
>>> reproducibility beyond analysis to include simulation initialization,<br>
>>> runtime, and final, reduced data products. Furthermore, I believe it<br>
>>> should be able to do this in a cross-code manner: imagine having a set<br>
>>> of descriptions (perhaps in the form of yt scripts, perhaps in some<br>
>>> other machine/human readable format) that describe initial conditions,<br>
>>> runtime parameters, analysis outputs and data products that could be<br>
>>> run on Enzo and Ramses. We could move beyond code comparison test<br>
>>> problems to real inter-code reproducibility.<br>
>><br>
>> Yes. Yes, and more yes; I firmly believe in this. Looking,<br>
>> realistically, at where we are and where we are going, I believe this<br>
>> is an utterly feasible goal, and the timescale is not terribly great<br>
>> -- effort simply needs to be applied in that direction.<br>
>><br>
>> We can have a longer discussion about this, but I think having this<br>
>> item in the mission statement for now is sufficient.<br>
>><br>
>>> Finally, I think that Britton is right that we should also continue to<br>
>>> emphasize that yt is a tool for physical reasoning on simulation data,<br>
>>> and that *it*, not *you the user* make all necessary manipulations to<br>
>>> get simulation data to physical quantities.<br>
>>><br>
>>> Thanks again for starting such an interesting discussion. I look<br>
>>> forward to moving forward with yt.<br>
>>><br>
>>> j<br>
>>><br>
>>> On Mon, Jun 13, 2011 at 4:23 PM, Brian O'Shea<<a href="mailto:bwoshea@gmail.com">bwoshea@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Hi Matt,<br>
>>>><br>
>>>> This may not be something specifically for the mission statement<br>
>>>> (depending<br>
>>>> on how wordy we want to get), but I'm very interested in using yt (or<br>
>>>> something that encompasses yt) as a workflow tool so that my simulations<br>
>>>> are<br>
>>>> completely reproducible. What I could imagine is something like this:<br>
>><br>
>> I very much like the workflow you laid out, although I would contend<br>
>> we should address more directly the task of running the simulation.<br>
>> On some level, it becomes a realizable goal to execute the main loop<br>
>> of the code in Python without any real overhead. This will have the<br>
>> side effect of providing much easier access to the data during the<br>
>> course of the simulation.<br>
>><br>
>> I would also scratch out "Enzo" and replace it with "Simulation Code"<br>
>> -- while pragmatically I recognize your simulations will likely be<br>
>> conducted in Enzo for the purposes of this provenance tracking, I feel<br>
>> it should be said that for the mission statement I believe in a<br>
>> code-neutral direction.<br>
>><br>
>> One difficulty here is the idea of actually moving the data. It is<br>
>> not clear the me that moving data around in file systems is a<br>
>> tractable, solvable problem. That is a good thing to strive for, but<br>
>> I personally can't wrap my head around it. Stephen? Britton?<br>
>><br>
>>>> 1. Generate initial conditions, cosmological or otherwise. IC<br>
>>>> parameter<br>
>>>> file goes into a database, along with details about the code that's used<br>
>>>> to<br>
>>>> generate my ICs (inits/MUSIC/grafic hash, outputs of make show-config<br>
>>>> and<br>
>>>> make show-flags, etc.)<br>
>>>><br>
>>>> 2. Run simulation. Run-related and performance information is<br>
>>>> collected in<br>
>>>> a database. (what supercomputer? How many CPUs? Environmental<br>
>>>> variables?<br>
>>>> Which version of MPI? What date(s) did the job run on? What nodes?<br>
>>>> Copy<br>
>>>> of Enzo restart parameter files and perhaps hierarchy files, for later<br>
>>>> query?)<br>
>>>><br>
>>>> 3. Back up Enzo data to mass storage (or perhaps some subset of the<br>
>>>> data,<br>
>>>> depending on how big the sim is). What directory is it in? Should it<br>
>>>> be<br>
>>>> world-readable, group-readable, etc.?<br>
>>>><br>
>>>> 4. Do analysis. Record all details of analysis and plot making, so<br>
>>>> that I<br>
>>>> can go back and retrace all details.<br>
>>>><br>
>>>> At that point, I would know _precisely_ how and with what<br>
>>>> commands/code/parameter files/etc. the plots that are in my papers, and<br>
>>>> everything leading up to that, is generated. This helps when you go<br>
>>>> back to<br>
>>>> deal with the referee ("how DID I make that stupid plot? What was<br>
>>>> sigma8<br>
>>>> again?"), but also for reproducibility, since in principle somebody<br>
>>>> could<br>
>>>> just go back, look at the database, and be able to do precisely what I<br>
>>>> did.<br>
>>>> Also, if somebody wanted to use archival data - something we hope to do<br>
>>>> more<br>
>>>> of in the future, as simulations grow in expense and complexity -<br>
>>>> there'd be<br>
>>>> no confusion about the provenance of that data.<br>
>>>><br>
>>>> If I had to sum this up in a sentence, it'd be "Transform yt into a tool<br>
>>>> for<br>
>>>> easily and transparently tracking all aspects of simulation generation,<br>
>>>> execution, and analysis for the purposes of reproducibility."<br>
>><br>
>> That's a great sentence.<br>
>><br>
>> Britton: I like your additions very much. It had completely slipped<br>
>> my mind that one of the most useful features of yt is its physical and<br>
>> geometric object selection.<br>
>><br>
>> Chris: I don't think you are stepping outside the scope of what we<br>
>> could generously call "The yt project" with what you mention. There<br>
>> are the technical goals, and the broader community goals. The goals<br>
>> of open science, reproducibility, and cultivating a community of<br>
>> scientists willing to share scripts, analysis routines, and even<br>
>> analysis modules are certainly part of what I think we are all<br>
>> striving for. And this goal isn't composed of just deploying<br>
>> infrastructure, rolling it out, but also providing a welcoming and<br>
>> friendly community of people willing to help. For instance, it's<br>
>> great that scripts written to generate phase plots from Orion outputs<br>
>> can be used nearly unmodified on Enzo outputs. (I remember when Jeff<br>
>> worked so hard to make this so --<br>
>> <a href="http://www.flickr.com/photos/matthewturk/2598141965/" target="_blank">http://www.flickr.com/photos/matthewturk/2598141965/</a> ) But even more<br>
>> than that, I think it's amazing that people are willing to share these<br>
>> scripts.<br>
>><br>
>> So yes, let's bake that right into the mission statement.<br>
>><br>
>> As for your comments about the microphysical solvers, believe me when<br>
>> I say they are not falling on deaf ears. Moving toward an open<br>
>> source, community-driven model for microphysical solvers is an issue<br>
>> near and dear to my own heart, having spent several years of my life<br>
>> writing a primordial chemistry solver. I believe there is a place for<br>
>> interfacing with that sort of project and endeavor inside yt -- in<br>
>> particular, interfacing with specific APIs and so forth to seamlessly<br>
>> calculate cooling times or EOS or opacities. Let's revisit this issue<br>
>> in the future.<br>
>><br>
>> (Although, if we step back for a second and look at what's in yt ...<br>
>> boundary condition calculations, cooling time calculations, gravity,<br>
>> ... the mind does wander.)<br>
>><br>
>> The revised bullet points I have:<br>
>><br>
>> = What is the mission? =<br>
>> * To create a fun, community-led, open source tool for asking and<br>
>> answering astrophysical questions through simulations, analysis and<br>
>> visualization that allows one to ask astrophysical questions of<br>
>> simulation data independent of the code used to produce that data.<br>
>> * To create a friendly, helpful community of scientists<br>
>> * To further the goals of Open Science<br>
>> * To construct an environment that encompasses the generation of<br>
>> data, starting from initial conditions, through simulations, and<br>
>> finally resulting in publication-quality plots<br>
>> * To create reproducible, cross-code questions and answers from<br>
>> astrophysical data<br>
>> * To present simulation data in physical terms, rather than strictly<br>
>> in simulation and data format terms<br>
>> * To construct a consistent language for asking questions of<br>
>> simulation data from many sources<br>
>> * To encourage researchers to participate in constructing a community<br>
>> code<br>
>> * To provide a place to create and share analysis codes, recipes, and<br>
>> other things that can be helpful to others seeking to answer similar<br>
>> scientific questions.<br>
>><br>
>> The next step in this is to try to distill it down into a sentence or<br>
>> two. I've included my first pass at this. Not all items have to be<br>
>> included -- they can be shuffled off and left implicit in the proper<br>
>> mission statement, but can show up in the broader directions. The<br>
>> ultimate goal of this is to provide both the short-form "elevator<br>
>> pitch" and then augment that with what we could generously call<br>
>> strategy documents.<br>
>><br>
>> Draft 1:<br>
>><br>
>> The yt project aims to produce an integrated science environment for<br>
>> asking and answering astrophysical questions, encompassing the<br>
>> creation of initial conditions, the execution of simulations and the<br>
>> detailed exploration and visualization of the resultant data.<br>
>> Development of yt is driven by a commitment to Open Science principles<br>
>> as manifested in participatory development, reproducibility, a<br>
>> friendly and helpful community of users and developers, and Free and<br>
>> Libre Open Source Software.<br>
>><br>
>> I'm not terribly satisfied with this draft. I don't quite know how to<br>
>> work in two things that I think should be stated -- that the end goal<br>
>> is, ideally, a community project (whose bus factor is equal to the<br>
>> number of users :) and that we want to focus on the physical<br>
>> underpinnings of simulations when asking questions rather than, say,<br>
>> the specifics of unformatted fortran or HDF5. I think that the<br>
>> broader focus (as an integrated science environment) comes across, but<br>
>> the other core aspects are a bit underserved.<br>
>><br>
>> Edits and suggestions?<br>
>><br>
>> Thanks again, everyone. I'm glad we're having this conversation.<br>
>><br>
>> -Matt<br>
>><br>
>>>> Anyway, maybe that's unrealistic, but it'd be awesome. The few workflow<br>
>>>> tools that I have been exposed to suffer from excessive generality, and<br>
>>>> thus<br>
>>>> are a bit too cumbersome to be easy to use, and thus too cumbersome to<br>
>>>> be<br>
>>>> actually used.<br>
>>>><br>
>>>> --Brian<br>
>>>><br>
>>>> On Mon, Jun 13, 2011 at 12:43 PM, Matthew Turk<<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Hi everyone,<br>
>>>>><br>
>>>>> I hope you'll take the opportunity to read and respond to this email,<br>
>>>>> even if you're not a heavy-developer, or even a heavy-user, of yt.<br>
>>>>> Your feedback and contributions would be greatly, greatly appreciated,<br>
>>>>> particularly as this will help guide where yt development,<br>
>>>>> community-building and (optimistically) use will go. I know that<br>
>>>>> sometimes the signal-to-noise on the yt lists can be a bit low, but I<br>
>>>>> think this is a particularly useful discussion to have.<br>
>>>>><br>
>>>>> A few of us have been brainstorming, in person, in IRC, etc about the<br>
>>>>> direction yt has been going. There are a number of reasons for doing<br>
>>>>> this -- to provide focus, to provide an idea of the<br>
>>>>> off-in-the-distance goal, and to have a public statement of what we're<br>
>>>>> about, which shows ambition, concern for the values that go into a<br>
>>>>> scientific code, and an interest in providing access to that code.<br>
>>>>> This boils down to coming up with a mission statement, which will help<br>
>>>>> both focus our goals on what we want to provide, as well as describe<br>
>>>>> those areas we do not want to provide. Much of this is based on the<br>
>>>>> contents of “The Art of Community” by Jono Bacon, specifically around<br>
>>>>> page 71 in the PDF available on <a href="http://www.artofcommunityonline.org/get/" target="_blank">www.artofcommunityonline.org/get/</a> .<br>
>>>>><br>
>>>>> “Mission statements are intended to be consistent and should rarely<br>
>>>>> change, even if the tasks that achieve that mission change regularly.<br>
>>>>> When building your mission statement, always have its longevity in<br>
>>>>> mind. Remember, your mission statement is your slam-dunking, audacious<br>
>>>>> goal. For many communities these missions can take decades or even<br>
>>>>> longer to achieve. Their purpose is to not only describe the finish<br>
>>>>> line, but to help the community stay on track.”<br>
>>>>><br>
>>>>> To develop a mission statement, which will act as a precursor to a<br>
>>>>> strategic plan, we need to construct answers to three questions.<br>
>>>>> These will provide the initial basis for a broader mission statement.<br>
>>>>> For reference, here are some “principles” we came up with several<br>
>>>>> years ago:<br>
>>>>><br>
>>>>> <a href="http://yt.enzotools.org/principles.html" target="_blank">http://yt.enzotools.org/principles.html</a><br>
>>>>><br>
>>>>> As I mentioned above, a few of us have been spitballing answers to<br>
>>>>> these questions, and it has reached the point where we really need to<br>
>>>>> bring this forward, to conduct these discussions in public, to bring<br>
>>>>> some clarity and engagement to the process. Ultimately, once we have<br>
>>>>> sketched out a couple broad goals and bullet points, this can then be<br>
>>>>> distilled into a short, pithy block of text that serves as a "Mission<br>
>>>>> Statement." Below are some potential bullet points, but I feel<br>
>>>>> strongly that it's important that these get refined and discussed.<br>
>>>>><br>
>>>>> = What is the mission? =<br>
>>>>> * To create a fun, community-led, open source tool for asking and<br>
>>>>> answering astrophysical questions through simulations, analysis and<br>
>>>>> visualization<br>
>>>>> * To create reproducible, cross-code questions and answers from<br>
>>>>> astrophysical data<br>
>>>>> * To construct a consistent language for asking questions of<br>
>>>>> simulation data from many sources<br>
>>>>> * To encourage researchers to participate in constructing a community<br>
>>>>> code<br>
>>>>><br>
>>>>> = What are the opportunities and areas of collaboration? =<br>
>>>>> * Development of new tools, new techniques, and adding support for new<br>
>>>>> codes.<br>
>>>>> * Adding components to the GUI<br>
>>>>> * Providing outreach-capable frontends<br>
>>>>> * Improving visualization qualities<br>
>>>>> * Adding new methods of accessing data<br>
>>>>> * Performance analysis& optimization<br>
>>>>> * Deployment to new platforms<br>
>>>>> * Designing new web pages<br>
>>>>> * Writing documentation and recipes<br>
>>>>> * Spreading the word<br>
>>>>> * Support for Cartesian non-astrophysical simulations (weather,<br>
>>>>> earthquakes)<br>
>>>>> * Extension to non-Cartesian coordinate systems<br>
>>>>> * Mentoring new developers<br>
>>>>><br>
>>>>> = What are the skills required? =<br>
>>>>> * Thoughtful process<br>
>>>>> * Careful quality control<br>
>>>>> * Ability to communicate<br>
>>>>> * An investment in “the answer”<br>
>>>>> * Eagerness to participate in an open fashion<br>
>>>>><br>
>>>>> What other bullets, ideas, inclinations do people have? If we can<br>
>>>>> start a discussion, maybe we can draft some text. This would<br>
>>>>> certainly help with focusing our strategies for presenting yt to<br>
>>>>> others, directing our development in conjunction with our scientific<br>
>>>>> goals, and collaborating as a community.<br>
>>>>><br>
>>>>> Thanks very much for any thoughts,<br>
>>>>><br>
>>>>> Matt<br>
>>>>> _______________________________________________<br>
>>>>> Yt-dev mailing list<br>
>>>>> <a href="mailto:Yt-dev@lists.spacepope.org">Yt-dev@lists.spacepope.org</a><br>
>>>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Yt-dev mailing list<br>
>>>> <a href="mailto:Yt-dev@lists.spacepope.org">Yt-dev@lists.spacepope.org</a><br>
>>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>>>><br>
>>>><br>
>>> _______________________________________________<br>
>>> Yt-dev mailing list<br>
>>> <a href="mailto:Yt-dev@lists.spacepope.org">Yt-dev@lists.spacepope.org</a><br>
>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>><br>
>> _______________________________________________<br>
>> Yt-dev mailing list<br>
>> <a href="mailto:Yt-dev@lists.spacepope.org">Yt-dev@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>><br>
> _______________________________________________<br>
> Yt-dev mailing list<br>
> <a href="mailto:Yt-dev@lists.spacepope.org">Yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
Yt-dev mailing list<br>
<a href="mailto:Yt-dev@lists.spacepope.org">Yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br>