Enzo 3.0 Development

[Sam Skillman]

Hi all,

With the recent movement on PRs, as well as some discussions on the IRC channel, I’d like to bring up the topic of Enzo 3.0 development.  

Current Status (per conversations with Matt Turk, Nathan Goldbaum, John Wise, others):

The current blocker is the fact that the main development was done inside the active-particles branch, which is no longer the appropriate name for 3.0 development which encompasses a much larger array of goals (Event Handling, Field Definitions, Communicators, Solvers, Configuration, I/O, Problem Initialization, etc).  

A while back we discussed branch naming:

https://groups.google.com/forum/?hl=en&fromgroups=#!searchin/enzo-dev/Branch$20Naming/enzo-dev/NWnK3_4JnKk/XKBZIWLaGbEJ

I’d like to propose that we follow what was outlined by Matt:

“I think it would be best if we suddenly branched from week-of-code as

$BRANCHNAME .  Then, merge from active_particles.  Each of the other

changes that constitute a major, 3.0-targeted change will have their

own branch name (perhaps with a prefix?  I am not sure.)  Merges

between these sub-branches can be common, as many features will be

interrelated.  But merges back to this main branch could be considered

somewhat rare, and in fact could even constitute a "preview" version

of the eventual 3.0 code base.”

I’d like a +/- 1 on $BRANCHNAME  being enzo-dev  This would mean enzo-3.0 development would occur at http://bitbucket.org/enzo/enzo-3.0 in the branch enzo-dev.

To summarize the plan from here on out:

1) New branch called enzo-dev will become the new main line of development for 3.0 features, branched from week-of-code.

2) active_particles merged in to enzo-3.0/enzo-dev 

3) Further active_particles work can continue to be done in the active_particles branch or in a fork of enzo-3.0/enzo-dev, but either way would require future PRs to be accepted into the main enzo-3.0/ repository.

4) Other 3.0 development would occur in a fork of enzo-3.0 on the enzo-dev branch, and not on new named branches.  Inclusion to http://bitbucket.org/enzo/enzo-3.0 would also require PR acceptance.

Cheers,

Sam

[Matthew Turk]

On Mon, Mar 18, 2013 at 3:58 PM, Sam Skillman <samsk...@gmail.com> wrote:
> Hi all,
>
> With the recent movement on PRs, as well as some discussions on the IRC
> channel, I’d like to bring up the topic of Enzo 3.0 development.

(reminder: http://enzo-project.org/irc.html or irc.freenode.org #enzo )

>
> Current Status (per conversations with Matt Turk, Nathan Goldbaum, John
> Wise, others):
> The current blocker is the fact that the main development was done inside
> the active-particles branch, which is no longer the appropriate name for 3.0
> development which encompasses a much larger array of goals (Event Handling,
> Field Definitions, Communicators, Solvers, Configuration, I/O, Problem
> Initialization, etc).
>
> A while back we discussed branch naming:
> https://groups.google.com/forum/?hl=en&fromgroups=#!searchin/enzo-dev/Branch$20Naming/enzo-dev/NWnK3_4JnKk/XKBZIWLaGbEJ
>
> I’d like to propose that we follow what was outlined by Matt:
> “I think it would be best if we suddenly branched from week-of-code as
> $BRANCHNAME . Then, merge from active_particles. Each of the other
> changes that constitute a major, 3.0-targeted change will have their
> own branch name (perhaps with a prefix? I am not sure.) Merges
> between these sub-branches can be common, as many features will be
> interrelated. But merges back to this main branch could be considered
> somewhat rare, and in fact could even constitute a "preview" version
> of the eventual 3.0 code base.”
>
> I’d like a +/- 1 on $BRANCHNAME being enzo-dev This would mean enzo-3.0
> development would occur at http://bitbucket.org/enzo/enzo-3.0 in the branch
> enzo-dev.

I think I like having a unified branch name with multiple bookmarks.
I am +1 on this as long as consensus can be built that this is what
we're building toward -- which is a process I don't think we have in
place right now. yt has YTEPs, but the similar Enzo effort never
really took off, although John and I did write a few. ;-) My initial
feeling is enzo-3.0-dev, but yours is better.

>
> To summarize the plan from here on out:
>
> 1) New branch called enzo-dev will become the new main line of development
> for 3.0 features, branched from week-of-code.
> 2) active_particles merged in to enzo-3.0/enzo-dev
> 3) Further active_particles work can continue to be done in the
> active_particles branch or in a fork of enzo-3.0/enzo-dev, but either way
> would require future PRs to be accepted into the main enzo-3.0/ repository.
> 4) Other 3.0 development would occur in a fork of enzo-3.0 on the enzo-dev
> branch, and not on new named branches. Inclusion to
> http://bitbucket.org/enzo/enzo-3.0 would also require PR acceptance.

+1. bookmarks >> named_branches for this.

On IRC, I was also reminded of a document I wrote up last Summer that
I didn't really share around very much. It's pretty presumptuous and,
frankly, I am pretty self-conscious of it. Anyway, it cobbles
together a lot of ideas that have been grabbed from here and there --
discussions, other codes, other systems of development, cello, etc. A
few people suggested I share it here, so I am including a link.

https://docs.google.com/document/d/1wxXc_9d2Uf5JiXcxHu1SGhimlciTGn0ipooPsI-0SBs/edit#

I've enabled commenting, but not editing. If you'd like to be added
as having the ability to edit, let me know and I will happily do so.
I think it's not really appropriate to be titled "Roadmap" but rather
"Brainstorming," and of course I think it's better viewed as a
discussion starter than anything else. As long as we're looking at
decoupling AP from what we've been calling enzo-3.0, I think perhaps
we can build up some momentum.

>
> Cheers,
> Sam
>
> --
> You received this message because you are subscribed to the Google Groups
> "enzo-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to enzo-dev+u...@googlegroups.com.
> To post to this group, send email to enzo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Nathan Goldbaum]

+1 on the plan outlined in this e-mail.

Like I said on IRC, I'm happy to do the merge from active_particles to the new enzo-dev branch.

-Nathan

[Cameron Hummels]

+1 to Sam's and Matt's suggestions.

--
Cameron Hummels

Postdoctoral Researcher

Steward Observatory

University of Arizona

http://chummels.org

[Britton Smith]

+1 to enzo-dev branch.

[Michael Kuhlen]

+1, both to enzo-dev branch and to using bookmarks instead of new branches.

*********************************************************************
*                                                                   *
*  Dr. Michael Kuhlen              Theoretical Astrophysics Center  *
*  email: m...@astro.berkeley.edu   UC Berkeley                      *
*  cell phone: (831) 588-1468      B-116 Hearst Field Annex # 3411  *
*  skype username: mikekuhlen      Berkeley, CA 94720               *
*                                                                   *
*********************************************************************

[gbry...@gmail.com]

+1

[Sam Skillman]

Hi all,

Okay, let's go one more day to allow anyone to speak up with an objection (and please do if you do object!) or any other discussion.  Then we'll coordinate and make it so.  I will work with anyone who feels like helping out on updating this page:  

https://enzo.readthedocs.org/en/latest/developer_guide/ModificationIntro.html

outlining the steps for maneuvering bitbucket, forks, and bookmarks.

Cheers,

Sam

[j s oishi]

+1 to enzo-dev and the bookmarks and the Plan.

[Brian O'Shea]

+1 to the plan outlined in this email.

[Sam Skillman]

Hi again,

I've posted a PR that includes the new enzo-dev branch on the enzo-3.0 repository:

https://bitbucket.org/enzo/enzo-3.0/pull-request/41/branching-to-enzo-dev-updating-dev-docs/diff

In it are updated developer guide docs on how to develop using mercurial bookmarks instead of branches.

Please feel free to comment on the docs update, and once this PR is accepted, Nathan can then manually merge the active particles branch into the enzo-dev branch, and I suppose post that as a big PR (with conflicts already resolved) from his enzo-3.0 fork to the main line. 

Cheers,

Sam

[Nathan Goldbaum]

Hi all,

Before I merge the active particles branch into Sam's new enzo-dev branch, I want to check if it's ok to pull in the tip of the enzo-dev repository.  

We last pulled from the enzo-dev repository at the beginning of November during the Georgia Tech workshop, so enzo-3.0 is missing the contents of every PR since #76, including the new test suite, the fixes to the gravity solver, and a number of other bug fixes and improvements.

Since the MHDCT PR still hasn't been accepted, I don't think there are any major, invasive changes to the codebase that will affect the changes we've made in enzo-3.0.  I'm not sure what to do after MHDCT is merged in but hopefully that will be doable.  In any case, I think it's important to keep the enzo 3.0 repository in sync with the 2.X repository so we don't miss out on bugfixes in places where the two repositories share code.

Please let me know if you disagree so we can come up with a plan for porting bugfixes to the 3.0 codebase.

-Nathan

[Michael Kuhlen]

The ever elusive new-config is based on the active particles branch. I believe (hope) it won't be that bad to merge it in after Nathan's merge, under its own bookmark of course. Unfortunately changes made to enzo-dev since enzo-3.0/active_particles branched off often require additional mods to the new-config stuff: any time a new parameter is created, for example, or if a problem initializer is changed. But that's just the nature of the game, and I'm resigned to a 3rd iteration through. I'd like to advocate for new-config being the very next major change to be merged in after active_particles + current enzo-dev, because it's just going to get old keeping up with new changes. From then on development in enzo-3.0 would have to use new-config. Merging in changes from enzo-dev (if they introduce new parameters or modify problem initializers) would then become a bit more labor intensive, unless we also switch enzo-dev over to new-config.

I'm not going to be able to devote time to this until the second week of April, but then I'm committed to making this merge happen.

Mike

[Matthew Turk]

Hi Mike,

On Thu, Mar 21, 2013 at 2:26 AM, Michael Kuhlen <m...@astro.berkeley.edu> wrote:
> The ever elusive new-config is based on the active particles branch. I
> believe (hope) it won't be that bad to merge it in after Nathan's merge,
> under its own bookmark of course. Unfortunately changes made to enzo-dev
> since enzo-3.0/active_particles branched off often require additional mods
> to the new-config stuff: any time a new parameter is created, for example,
> or if a problem initializer is changed. But that's just the nature of the
> game, and I'm resigned to a 3rd iteration through. I'd like to advocate for
> new-config being the very next major change to be merged in after
> active_particles + current enzo-dev, because it's just going to get old
> keeping up with new changes. From then on development in enzo-3.0 would have
> to use new-config. Merging in changes from enzo-dev (if they introduce new
> parameters or modify problem initializers) would then become a bit more
> labor intensive, unless we also switch enzo-dev over to new-config.
>

I am +1 on new-config going in, and +1 on it being the next big thing.
Right now AP would benefit from it a great deal.

> I'm not going to be able to devote time to this until the second week of
> April, but then I'm committed to making this merge happen.
>

This might be unpopular. But, since you have a working converter, I
would like to propose that we disable old-config. Keeping both around
will only push things further and further out of sync. And, perhaps
most helpfully, if we intentionally cause conflicts with
ReadParameterFile.C / WriteParameterFile.C, we will be sure not to
miss any new parameters that come along during subsequent merges from
the 2.x branch.

My concern is that if we continue keeping both around, trying to keep
them in sync, we have a similar merge problem ... just a different
one.

Also, thanks for your work on this -- it's going to be awesome.

-Matt

[Nathan Goldbaum]

I agree on disabling the old config style.  I'm perfectly happy to work on manually converting things.

[j s oishi]

I also +1 disabling oldconfig. If we're switching, let's switch.

[Britton Smith]

+1 on only new config. To the future!

[Nathan Goldbaum]

Hi all,

I've opened a pull request that closes the active_particles branch: https://bitbucket.org/enzo/enzo-3.0/pull-request/43/merging-the-active_particles-branch-as/diff

It's a very large diff so bitbucket has trouble displaying it.  If you want to see the diff in your terminal, do:

hg diff -r 1d32a19:c05517e12448

As I note in the pull request message, I'm not able to get bitwise identical results compared to a gold standard generated using the tip of enzo-dev.  I'm not sure why that is, although I do know that the differences only show up in 1D and 2D AMR tests with shocks.

I'm not sure if the differences are worth worrying about and I'm curious if anyone has a feeling for whether we should worry about it before these changes get merged in.

Cheers,

Nathan

[Nathan Goldbaum]

Hi all,

Last week, Sam Skillman pointed out a mistake I made in merging that caused inconsistent code to be executed in the subgrid flux correction code. After fixing the issue, it appears that all of the answer tests in the push suite pass.

The PR includes more than 1000 changesets, including all of the active particles work as well as all enzo-dev commits since November.  Unfortunately, this means the diff is too large to render on bitbucket.  It is possible to generate the diff on a local copy of the repository using `hg diff,` however since the diff is so large it's pretty much impossible to look at the changes in detail.

If anyone has any ideas about how to handle the merge, I'd love to hear it.

I've added Stephen Skory, Matt Turk, and John Wise as reviewers for the PR since they've been heavily involved in active particle development.  If anyone else would like to take a look and comment, please feel free.

Once this is merged in, we should be able to merge in NewConfig and begin work on other backwards incompatible changes.

-Nathan

>> >>>> >>>>> an email to enzo-dev+unsubscribe@googlegroups.com.

>> >>>> >>>>> To post to this group, send email to enzo...@googlegroups.com.
>> >>>> >>>>> Visit this group at
>> >>>> >>>>> http://groups.google.com/group/enzo-dev?hl=en.
>> >>>> >>>>> For more options, visit
>> >>>> >>>>> https://groups.google.com/groups/opt_out.
>> >>>> >>>>>
>> >>>> >>>>>
>> >>>> >>>>>
>> >>>> >>>>>
>> >>>> >>>>> --
>> >>>> >>>>> You received this message because you are subscribed to the
>> >>>> >>>>> Google
>> >>>> >>>>> Groups "enzo-dev" group.
>> >>>> >>>>> To unsubscribe from this group and stop receiving emails from
>> >>>> >>>>> it,
>> >>>> >>>>> send

>> >>>> >>>>> an email to enzo-dev+unsubscribe@googlegroups.com.

>> >>>> >>>>> To post to this group, send email to enzo...@googlegroups.com.
>> >>>> >>>>> Visit this group at
>> >>>> >>>>> http://groups.google.com/group/enzo-dev?hl=en.
>> >>>> >>>>> For more options, visit
>> >>>> >>>>> https://groups.google.com/groups/opt_out.
>> >>>> >>>>>
>> >>>> >>>>>
>> >>>> >>>>
>> >>>> >>>>
>> >>>> >>>>
>> >>>> >>>>
>> >>>> >>>> --
>> >>>> >>>> Cameron Hummels
>> >>>> >>>> Postdoctoral Researcher
>> >>>> >>>> Steward Observatory
>> >>>> >>>> University of Arizona
>> >>>> >>>> http://chummels.org
>> >>>> >>>>
>> >>>> >>>> --
>> >>>> >>>> You received this message because you are subscribed to the
>> >>>> >>>> Google
>> >>>> >>>> Groups "enzo-dev" group.
>> >>>> >>>> To unsubscribe from this group and stop receiving emails from
>> >>>> >>>> it,
>> >>>> >>>> send

>> >>>> >>>> an email to enzo-dev+unsubscribe@googlegroups.com.

>> >>>> >>>> To post to this group, send email to enzo...@googlegroups.com.
>> >>>> >>>> Visit this group at
>> >>>> >>>> http://groups.google.com/group/enzo-dev?hl=en.
>> >>>> >>>> For more options, visit
>> >>>> >>>> https://groups.google.com/groups/opt_out.
>> >>>> >>>>
>> >>>> >>>>
>> >>>> >>>
>> >>>> >>>
>> >>>> >>> --
>> >>>> >>> You received this message because you are subscribed to the
>> >>>> >>> Google
>> >>>> >>> Groups
>> >>>> >>> "enzo-dev" group.
>> >>>> >>> To unsubscribe from this group and stop receiving emails from it,
>> >>>> >>> send an

>> >>>> >>> email to enzo-dev+unsubscribe@googlegroups.com.

>> >>>> >> email to enzo-dev+unsubscribe@googlegroups.com.

>> >>>> >> To post to this group, send email to enzo...@googlegroups.com.
>> >>>> >> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>> >>>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> --
>> >>>> >> You received this message because you are subscribed to the Google
>> >>>> >> Groups
>> >>>> >> "enzo-dev" group.
>> >>>> >> To unsubscribe from this group and stop receiving emails from it,
>> >>>> >> send an

>> >>>> >> email to enzo-dev+unsubscribe@googlegroups.com.

>> >>>> >> To post to this group, send email to enzo...@googlegroups.com.
>> >>>> >> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>> >>>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>>> >>
>> >>>> >>
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> > You received this message because you are subscribed to the Google
>> >>>> > Groups
>> >>>> > "enzo-dev" group.
>> >>>> > To unsubscribe from this group and stop receiving emails from it,
>> >>>> > send
>> >>>> > an

>> >>>> > email to enzo-dev+unsubscribe@googlegroups.com.

>> >>>> > To post to this group, send email to enzo...@googlegroups.com.
>> >>>> > Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>> >>>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >>>> >
>> >>>> >
>> >>>>
>> >>>> --
>> >>>> You received this message because you are subscribed to the Google
>> >>>> Groups "enzo-dev" group.
>> >>>> To unsubscribe from this group and stop receiving emails from it,
>> >>>> send

>> >>>> an email to enzo-dev+unsubscribe@googlegroups.com.

>> >>>> To post to this group, send email to enzo...@googlegroups.com.
>> >>>> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>> >>>> For more options, visit https://groups.google.com/groups/opt_out.
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google
>> >>> Groups
>> >>> "enzo-dev" group.
>> >>> To unsubscribe from this group and stop receiving emails from it, send
>> >>> an

>> >>> email to enzo-dev+unsubscribe@googlegroups.com.

>> >>> To post to this group, send email to enzo...@googlegroups.com.
>> >>> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>> >>> For more options, visit https://groups.google.com/groups/opt_out.
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "enzo-dev" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an

>> >> email to enzo-dev+unsubscribe@googlegroups.com.

>> >> To post to this group, send email to enzo...@googlegroups.com.
>> >> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "enzo-dev" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an

>> >> email to enzo-dev+unsubscribe@googlegroups.com.

>> >> To post to this group, send email to enzo...@googlegroups.com.
>> >> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >>
>> >
>> >
>> >
>> >
>> > --
>> > *********************************************************************
>> > *                                                                   *
>> > *  Dr. Michael Kuhlen              Theoretical Astrophysics Center  *
>> > *  email: m...@astro.berkeley.edu   UC Berkeley                      *
>> > *  cell phone: (831) 588-1468      B-116 Hearst Field Annex # 3411  *
>> > *  skype username: mikekuhlen      Berkeley, CA 94720               *
>> > *                                                                   *
>> > *********************************************************************
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "enzo-dev" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an

>> > email to enzo-dev+unsubscribe@googlegroups.com.

>> > To post to this group, send email to enzo...@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "enzo-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to enzo-dev+unsubscribe@googlegroups.com.

>> To post to this group, send email to enzo...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "enzo-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to enzo-dev+unsubscribe@googlegroups.com.

> To post to this group, send email to enzo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "enzo-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to enzo-dev+unsubscribe@googlegroups.com.

To post to this group, send email to enzo...@googlegroups.com.
Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "enzo-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to enzo-dev+unsubscribe@googlegroups.com.

[Nathan Goldbaum]

Oops, it looks like a made an error earlier and didn't properly run the answer tests.  After regenerating the answers and rerunning the tests correctly, I now see all tests passing in the push suite, except for PhotonTestAMR. I would guess that tests fails for the exact same reason Dave Collins was seeing failures with the MHDCT changes.

[Matthew Turk]

Hi Nathan,

On Mon, Apr 15, 2013 at 5:35 PM, Nathan Goldbaum <natha...@gmail.com> wrote:
> Hi all,
>

> Last week, Sam Skillman pointed out a mistake I made in merging that caused
> inconsistent code to be executed in the subgrid flux correction code. After
> fixing the issue, it appears that all of the answer tests in the push suite
> pass.
>
> The PR includes more than 1000 changesets, including all of the active
> particles work as well as all enzo-dev commits since November.
> Unfortunately, this means the diff is too large to render on bitbucket. It
> is possible to generate the diff on a local copy of the repository using `hg
> diff,` however since the diff is so large it's pretty much impossible to
> look at the changes in detail.

I think we should consider this essentially unreviewable.
Unfortunately, the problem here is that all of the changes -- which,
in reality, are not that extensive -- are masked by the changes that
resulted from the re-organization.

However, this can be addressed by manually inspecting individual files
for changes on the command line. I'm not suggesting that this is the
right way to go, but it is possible.

>
> If anyone has any ideas about how to handle the merge, I'd love to hear it.

For starters, I think before we can consider merging, we should add a
test problem that tests actual star particles -- Cen & Ostriker, for
instance, which to my recollection is one of the more commonly used
ones. My understanding is that the current state of Active Particles,
the branch, is that hte only major changes in functionality:

1) Addition of active particles
2) Removal of some older functionality for star particles which may or
may not now correctly function in the new framework
3) Removal of "cruft" routines like the non-refactored GridIO

Is that roughly correct?

My concern is that unless we have "star" particles working as they do
in 2.x, we will not be able to have a large base of people who can
test this. For instance, I've talked to a couple people who said,
"Yeah, I'd love to test out 3.0 and the active particles stuff, but
when I did, it just didn't work for my simulations. So I stopped."
Staging our way in is good, but before we make this the default of the
development repo, I think we should ensure we can at least have people
on board. Adding a test case that runs with star particles will be a
good measure of that.

>
> I've added Stephen Skory, Matt Turk, and John Wise as reviewers for the PR
> since they've been heavily involved in active particle development. If
> anyone else would like to take a look and comment, please feel free.
>
> Once this is merged in, we should be able to merge in NewConfig and begin
> work on other backwards incompatible changes.

I would lobby to go in roughly this order for the big changes I am
most invested in seeing land in a 3.0:

1) Active particles / re-org
2) New-config
3) Field objects (pervasive, not the overlay that is in a pull request now)
4) Event handling

(4, for what it's worth, has been on-deck and ready to go for a while,
but never issued as a PR.)

>>> >> >>>> >>>>> an email to enzo-dev+u...@googlegroups.com.

>>> >> >>>> >>>>> To post to this group, send email to
>>> >> >>>> >>>>> enzo...@googlegroups.com.
>>> >> >>>> >>>>> Visit this group at
>>> >> >>>> >>>>> http://groups.google.com/group/enzo-dev?hl=en.
>>> >> >>>> >>>>> For more options, visit
>>> >> >>>> >>>>> https://groups.google.com/groups/opt_out.
>>> >> >>>> >>>>>
>>> >> >>>> >>>>>
>>> >> >>>> >>>>>
>>> >> >>>> >>>>>
>>> >> >>>> >>>>> --
>>> >> >>>> >>>>> You received this message because you are subscribed to the
>>> >> >>>> >>>>> Google
>>> >> >>>> >>>>> Groups "enzo-dev" group.
>>> >> >>>> >>>>> To unsubscribe from this group and stop receiving emails
>>> >> >>>> >>>>> from
>>> >> >>>> >>>>> it,
>>> >> >>>> >>>>> send

>>> >> >>>> >>>>> an email to enzo-dev+u...@googlegroups.com.

>>> >> >>>> >>>>> To post to this group, send email to
>>> >> >>>> >>>>> enzo...@googlegroups.com.
>>> >> >>>> >>>>> Visit this group at
>>> >> >>>> >>>>> http://groups.google.com/group/enzo-dev?hl=en.
>>> >> >>>> >>>>> For more options, visit
>>> >> >>>> >>>>> https://groups.google.com/groups/opt_out.
>>> >> >>>> >>>>>
>>> >> >>>> >>>>>
>>> >> >>>> >>>>
>>> >> >>>> >>>>
>>> >> >>>> >>>>
>>> >> >>>> >>>>
>>> >> >>>> >>>> --
>>> >> >>>> >>>> Cameron Hummels
>>> >> >>>> >>>> Postdoctoral Researcher
>>> >> >>>> >>>> Steward Observatory
>>> >> >>>> >>>> University of Arizona
>>> >> >>>> >>>> http://chummels.org
>>> >> >>>> >>>>
>>> >> >>>> >>>> --
>>> >> >>>> >>>> You received this message because you are subscribed to the
>>> >> >>>> >>>> Google
>>> >> >>>> >>>> Groups "enzo-dev" group.
>>> >> >>>> >>>> To unsubscribe from this group and stop receiving emails
>>> >> >>>> >>>> from
>>> >> >>>> >>>> it,
>>> >> >>>> >>>> send

>>> >> >>>> >>>> an email to enzo-dev+u...@googlegroups.com.

>>> >> >>>> >>>> To post to this group, send email to
>>> >> >>>> >>>> enzo...@googlegroups.com.
>>> >> >>>> >>>> Visit this group at
>>> >> >>>> >>>> http://groups.google.com/group/enzo-dev?hl=en.
>>> >> >>>> >>>> For more options, visit
>>> >> >>>> >>>> https://groups.google.com/groups/opt_out.
>>> >> >>>> >>>>
>>> >> >>>> >>>>
>>> >> >>>> >>>
>>> >> >>>> >>>
>>> >> >>>> >>> --
>>> >> >>>> >>> You received this message because you are subscribed to the
>>> >> >>>> >>> Google
>>> >> >>>> >>> Groups
>>> >> >>>> >>> "enzo-dev" group.
>>> >> >>>> >>> To unsubscribe from this group and stop receiving emails from
>>> >> >>>> >>> it,
>>> >> >>>> >>> send an

>>> >> >>>> >>> email to enzo-dev+u...@googlegroups.com.

>>> >> >>>> >> email to enzo-dev+u...@googlegroups.com.

>>> >> >>>> >> To post to this group, send email to
>>> >> >>>> >> enzo...@googlegroups.com.
>>> >> >>>> >> Visit this group at
>>> >> >>>> >> http://groups.google.com/group/enzo-dev?hl=en.
>>> >> >>>> >> For more options, visit
>>> >> >>>> >> https://groups.google.com/groups/opt_out.
>>> >> >>>> >>
>>> >> >>>> >>
>>> >> >>>> >>
>>> >> >>>> >> --
>>> >> >>>> >> You received this message because you are subscribed to the
>>> >> >>>> >> Google
>>> >> >>>> >> Groups
>>> >> >>>> >> "enzo-dev" group.
>>> >> >>>> >> To unsubscribe from this group and stop receiving emails from
>>> >> >>>> >> it,
>>> >> >>>> >> send an

>>> >> >>>> >> email to enzo-dev+u...@googlegroups.com.

>>> >> >>>> >> To post to this group, send email to
>>> >> >>>> >> enzo...@googlegroups.com.
>>> >> >>>> >> Visit this group at
>>> >> >>>> >> http://groups.google.com/group/enzo-dev?hl=en.
>>> >> >>>> >> For more options, visit
>>> >> >>>> >> https://groups.google.com/groups/opt_out.
>>> >> >>>> >>
>>> >> >>>> >>
>>> >> >>>> >
>>> >> >>>> >
>>> >> >>>> > --
>>> >> >>>> > You received this message because you are subscribed to the
>>> >> >>>> > Google
>>> >> >>>> > Groups
>>> >> >>>> > "enzo-dev" group.
>>> >> >>>> > To unsubscribe from this group and stop receiving emails from
>>> >> >>>> > it,
>>> >> >>>> > send
>>> >> >>>> > an

>>> >> >>>> > email to enzo-dev+u...@googlegroups.com.

>>> >> >>>> > To post to this group, send email to enzo...@googlegroups.com.
>>> >> >>>> > Visit this group at
>>> >> >>>> > http://groups.google.com/group/enzo-dev?hl=en.
>>> >> >>>> > For more options, visit
>>> >> >>>> > https://groups.google.com/groups/opt_out.
>>> >> >>>> >
>>> >> >>>> >
>>> >> >>>>
>>> >> >>>> --
>>> >> >>>> You received this message because you are subscribed to the
>>> >> >>>> Google
>>> >> >>>> Groups "enzo-dev" group.
>>> >> >>>> To unsubscribe from this group and stop receiving emails from it,
>>> >> >>>> send

>>> >> >>>> an email to enzo-dev+u...@googlegroups.com.

>>> >> >>>> To post to this group, send email to enzo...@googlegroups.com.
>>> >> >>>> Visit this group at
>>> >> >>>> http://groups.google.com/group/enzo-dev?hl=en.
>>> >> >>>> For more options, visit https://groups.google.com/groups/opt_out.
>>> >> >>>>
>>> >> >>>>
>>> >> >>>
>>> >> >>>
>>> >> >>> --
>>> >> >>> You received this message because you are subscribed to the Google
>>> >> >>> Groups
>>> >> >>> "enzo-dev" group.
>>> >> >>> To unsubscribe from this group and stop receiving emails from it,
>>> >> >>> send
>>> >> >>> an

>>> >> >>> email to enzo-dev+u...@googlegroups.com.

>>> >> >>> To post to this group, send email to enzo...@googlegroups.com.
>>> >> >>> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>>> >> >>> For more options, visit https://groups.google.com/groups/opt_out.
>>> >> >>>
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> You received this message because you are subscribed to the Google
>>> >> >> Groups
>>> >> >> "enzo-dev" group.
>>> >> >> To unsubscribe from this group and stop receiving emails from it,
>>> >> >> send
>>> >> >> an

>>> >> >> email to enzo-dev+u...@googlegroups.com.

>>> >> >> To post to this group, send email to enzo...@googlegroups.com.
>>> >> >> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>>> >> >> For more options, visit https://groups.google.com/groups/opt_out.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> You received this message because you are subscribed to the Google
>>> >> >> Groups
>>> >> >> "enzo-dev" group.
>>> >> >> To unsubscribe from this group and stop receiving emails from it,
>>> >> >> send
>>> >> >> an

>>> >> >> email to enzo-dev+u...@googlegroups.com.

>>> >> > email to enzo-dev+u...@googlegroups.com.

>>> >> > To post to this group, send email to enzo...@googlegroups.com.
>>> >> > Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>>> >> > For more options, visit https://groups.google.com/groups/opt_out.
>>> >> >
>>> >> >
>>> >>
>>> >> --
>>> >> You received this message because you are subscribed to the Google
>>> >> Groups
>>> >> "enzo-dev" group.
>>> >> To unsubscribe from this group and stop receiving emails from it, send
>>> >> an

>>> >> email to enzo-dev+u...@googlegroups.com.

>>> >> To post to this group, send email to enzo...@googlegroups.com.
>>> >> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>>> >> For more options, visit https://groups.google.com/groups/opt_out.
>>> >>
>>> >>
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups
>>> > "enzo-dev" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> > an

>>> > email to enzo-dev+u...@googlegroups.com.

>>> > To post to this group, send email to enzo...@googlegroups.com.
>>> > Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>> >
>>> >
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "enzo-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an

>>> email to enzo-dev+u...@googlegroups.com.

>>> To post to this group, send email to enzo...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "enzo-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to enzo-dev+u...@googlegroups.com.

>> To post to this group, send email to enzo...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "enzo-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to enzo-dev+u...@googlegroups.com.

[Nathan Goldbaum]

Here's an idea: now that active particles and regular particles are completely detached, it should be possible to restore the old style star particle formation and feedback routines.

The functionality of star objects is completely replaced by active particles, so I don't think it's worth it to restore them.  On the other hand, things like simple star particles, dark matter particles, tracer particles, and must refine particles seem to be a somewhat poor fit for the active particles given the way the active particles are stored in memory.

[Britton Smith]

Hi Nathan,

My preference is not to return the original star particles to enzo-3.0, either as an interim solution or an admission of defeat.  As an interim solution, I think we all know that they will simply not get removed again.  For the other one, I think the active particle approach really is the way forward and it may end up being even more complicated to try and maintain both systems, both here and in yt.  I don't have a good feeling on the degree to which the traditional star particles "don't work" at the moment, but my feeling is that we just need to find the time, which is really the main limiter, to just fix them.  Would people be interested in an online sprint to try and get this patched up?  Again, I don't know exactly how much work is involved, but I am a representative of that group of people who aren't working on enzo-3.0 because of this, so I would definitely like to help get this back on track.

Britton

--

[Nathan Goldbaum]

Hi Britton,

Yes, a sprint on this would be useful.  I don't run cosmological boxes with large numbers of star particles, so any help from people with that sort of experience would be valuable.

I agree that reenabling old style star particle creation and feedback would be giving up on some level.  That suggestion was driven by a desire to get something working so more people could begin contributing to 3.0 development.

If we end up deciding not to go down that route, I think it would still be worthwhile to reenable the particle type field for the old style particles.  This sould make it possible to distinguish between star particles that do no feedback and dark matter particles, and also enable a straightforward (Identical to 2.X) implementation of tracer particles and must refine particles. 

It would be great if we could come up with a reference simulation (preferably one that can  be run on either one or a few processors) to compare against that would also be helpful as a benchmark.  Right now star particles are untested in the test suite, this would ameliorate that situation somewhat.

Cheers,

Nathan

[Michael Kuhlen]

I'm +1 on Britton's comment, that it would be a shame to have to maintain both old and new star particles. Let's do it once and do it right. I'd be happy to participate in the sprint.

Mike

--

You received this message because you are subscribed to the Google Groups "enzo-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enzo-dev+u...@googlegroups.com.
To post to this group, send email to enzo...@googlegroups.com.
Visit this group at http://groups.google.com/group/enzo-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Greg Bryan]

I agree that we don't want to maintain both, but I do think it would be worth keeping a light-weight particle type that can be used for dark matter, tracer particles, must-refine particles - in other words, any type that doesn't require any extra data.  If we feel this can be accomplished within the AP framework, that's fine, but frankly I'm skeptical that it can handle billions if particles efficiently.  That said, I don't want to bring back star particles, maybe just ParticleType.

Greg

[Britton Smith]

I think the AMRCosmology simulation in run/CosmologySimulation could be used as a test case.  It uses the Cen & Ostriker star particles and runs on one or two processors.  Greg has a good point about keeping around the lightweight machinery for non-active particles.  I'm on board with that.  Do we have any takers for an afternoon online sprint within the next couple weeks?  If so, maybe we should set it up and get this ship righted.

[Tom Abel]

I'd second Greg here.
It would be wonderful to have a light particle type which is distributed across processors and where particles are not inherently associated with grids but instead the particle layer aims to keep particles close to the grids that use them. This requires a fast routine that sorts particles into the grids that need them.

The hope is that this would avoid at least some of the many copy and delete operations of small arrays of particles and has the potential of avoiding some of the memory fragmentation (perhaps).

Additionally it would also make it much easier to try our tetrahedra based gravity solvers and couple them with gas dynamics.

Perhaps with some brainstorming we could come up with a good strategy to make this happen?
Best,
Tom

[Christine Simpson]

I am +1 on Greg's point.

> > +unsub...@googlegroups.com.

[Matthew Turk]

I'll sprint on this.

I think we can all probably agree that lightweight particles (like DM)
should remain lightweight, and that the particle type needs to come
back to support that. As I see it we could consider two types:

1) Lightweight particles, with no supplemental data (DM, tracer, must refine)
2) Heavyweight particles, with supplemental data (star particles and
active particles, which *are* different in the sense that SP are
lighter weight than most AP)

The issue I see with putting SP into AP is that SP are typically
column oriented, whereas AP are certainly row-oriented. We also need
to have some classes of particles that are replicated on all procs,
and some that aren't. SP would not be replicated; some types of AP
would be.

[Nathan Goldbaum]

I've set up a doodle poll with a few options over the next couple of weeks:

http://www.doodle.com/bn82adqmi3u476ur

These start (rather arbitrarily) at 11:00 PST to accomodate people on the east coast, and I expect the hangout to last for several hours, so you should still be able to drop in if you'll have trouble making it to the beginning.

-Nathan