#251 Merged at 5d66537
  1. Philipp Grete

Implementation of stochastic forcing (driving by an evolving field) as described by Schmidt et al. 2009 A&A 494, 127-145 http://dx.doi.org/10.1051/0004-6361:200809967

Includes documentation and test problem. Tested to work with MUSCL type HD and MHD solvers for 3D problems (MPI/non-MPI runs incl. restarts).

Any feedback and comments are welcome especially with regard to the implementation of the forcing as an additional class in Enzo.

Comments (31)

  1. Philipp Grete author

    I'm pretty sure that these tiny changes stem from including second order terms in the change of the total energy density. I commented the appropriate lines below.

      1. Sam Skillman

        All the extra failures are due to the gold standard not being updated after several recent PRs that change the gold standard were merged. I've set up a simpler way for me to update the gold when needed, so now it should be easier to update these faster. Re-testing on the current PRs are running now.

  2. Brian O'Shea

    It occurs to me that it would be helpful to cite, in the source code, the paper where this is all spelled out. I've added a few places where it's not particularly obvious what you're doing.

  3. Philipp Grete author

    The latest update incorporate (hopefully) all previous comments. I had to extend the RNG (by save and restore functions) in order to being able to resume stochastic forcing simulations in a deterministic way.

  4. dcollins4096

    It looks great. The only thing I think might be missing is proper support for MHD/MHDCT and <3d, since both MHD methods always require Vy and Vz. (This is a rare case, of course, but useful if one wants to do, say, ambipolar diffusion) I think I caught all the bits that I know will crash, but if you could double check if the anything else will choke if GridRank <3 and Vy or Vz exist that would be grand.

  5. Philipp Grete author

    I added MHDCT support and tested serial/MPI runs incl. restarts. In addition to changing the problem initialization file, I had to make further changes as Grid_*SourceTerms.C is only called by the MUSCL solvers. I considered to the existing Grid_AddRandomForcing to be the most appropriate place and changed it so that both types for forcing (Random and Stochastic) are supported along the same lines of code. Please have a second look, whether I missed something there or in case you think that these should be kept separate.

  6. dcollins4096

    I don't see any reason to not merge this, but there's still an outstanding failure from Jenkins. The report looks like noise. I'll merge this tomorrow if nobody says I shouldn't.

      1. Brian O'Shea

        @dcollins4096 , please hold off on hitting merge. I am going to regenerate the gold standard and test this PR vs. the regenerated standard. I expect it to pass - the problem with Jenkins is expected - but it's better to be safe than sorry. I will do it over the weekend if I can, but more likely Monday morning.

        1. Sam Skillman

          If someone tells me that it is okay to regenerate the gold and bump the version on jenkins, all the failures will dissappear. I sent an email/left a comment on another PR a while back (to the list or @Brian O'Shea maybe?) asking for someone to test a PR that got merged while Jenkins was down and has floating point differences that lead to all the current errors from what I can tell.

            1. Sam Skillman

              Great. Amazingly it looks like the machinery is all working. I ran http://srs.slac.stanford.edu/hudson/job/create-enzo-dev-gold/ which made a new gold, then moved a key file that is used to catalog the PRs that have been checked, and now all the outstanding PRs are being checked again against the new gold local-gold-007 (aka goldenenzo). http://srs.slac.stanford.edu/hudson/job/enzo-dev . If I could figure out the oauth issue it would comment on them all, but that probably won't happen today.

  7. Brian O'Shea

    OK, following up on this PR: in the new gold standard (http://srs.slac.stanford.edu/hudson/job/enzo-dev/239/) there are 33 test failures. These are the same test failures as before, and occur only in the DrivenTurbulence3D test problem. I concur with @Philipp Grete that this is due to differences in the treatment of energy. The differences are at an acceptable level, and I am going to merge this PR momentarily.

    @Philipp Grete , sorry for taking so long on this one!