Several places in the code require a subset of fields to be multiplied by density before conservative actions take place. As the code gets more complex, this logic has become cumbersome, so I'm replacing it with a function, MakeFieldConservative( field_type ).
I have two questions for the group.
First: I have identified the following routines that require this. Are there any others that y'all can think of? Grid_InterpolateFieldValues.C Grid_ProjectSolutionToParentGrid.C Grid_InterpolateBoundaryFromParent.C [FluxFix_]Grid_CorrectForRefinedFluxes.C
Second: FieldTypeNoInterpolate[] is examined in CorrectForRefinedFluxes and ProjectSolutionToParent, but not the two interpolation routines, InterpolateFieldValues and InterpolateBoundaryFromParent. As the array is called "NoInterpolate", this seems like an error to me. I don't fully understand this array, could someone comment on this? I looked only in the dev branch, hg id=ac7a5dacd12b on the bitbucket/enzo-dev repo. This is important as I consider including the check against that array in MakeFieldConservative, or, if it's not a condition that needs to be checked at each of these instances, there will be two conditionals in these conservative transform points.
The multiply is not done for Energy fields when Radiative Cooling is on, but this seems to only be done in CorrectForRefinedFluxes. Should that logic be applied in all cases?
Wait a second-- No, this is only in older branches, it has been removed since the mhdctmerge forked off, somewhere shortly after Week Of Code. I'm assuming this should, in fact, be off and [Total Gas]Energy should be flux-corrected even when radiativeCooling=1
> Several places in the code require a subset of fields to be multiplied > by density before conservative actions take place. As the code gets > more complex, this logic has become cumbersome, so I'm replacing it > with a function, MakeFieldConservative( field_type ).
> I have two questions for the group.
> First: I have identified the following routines that require this. > Are there any others that y'all can think of? > Grid_InterpolateFieldValues.C > Grid_ProjectSolutionToParentGrid.C > Grid_InterpolateBoundaryFromParent.C > [FluxFix_]Grid_CorrectForRefinedFluxes.C
> Second: FieldTypeNoInterpolate[] is examined in > CorrectForRefinedFluxes and ProjectSolutionToParent, but not the two > interpolation routines, InterpolateFieldValues and > InterpolateBoundaryFromParent. As the array is called > "NoInterpolate", this seems like an error to me. I don't fully > understand this array, could someone comment on this? I looked only > in the dev branch, hg id=ac7a5dacd12b on the bitbucket/enzo-dev repo. > This is important as I consider including the check against that array > in MakeFieldConservative, or, if it's not a condition that needs to be > checked at each of these instances, there will be two conditionals in > these conservative transform points.
FieldTypeNoInterpolate was my doing a while back, and it also confuses me why the necessary logic is not in InterpolateFieldValues or InterpolateBoundaryFromParent. I believe at some point it was in there, but it may have been removed due to the logic required to not interpolate a interpolate a field at all. The trick was that in addition to not being a conservative field that should first be multplied by density, some fields should use a different order interpolation. For example, the Mach number associated with a shock should really just be FirstOrderA where the 8 (in 3D) child cells should be exactly the same as the parent cell.
In any case, I would be a huge fan of modifying how this is handled because it has gotten out of control. I would also be in favor of a way to specify how fields should be interpolated, but perhaps that's a later project. As for how the Energy fields should be interpolated when radiative cooling is on, I really have no clue, so someone else should chime in.
I'd be happy to help if there is anything I can do.
Sam
On Thu, Dec 15, 2011 at 4:52 PM, David Collins <dcoll...@physics.ucsd.edu>wrote:
> The multiply is not done for Energy fields when Radiative Cooling is > on, but this seems to only be done in CorrectForRefinedFluxes. Should > that logic be applied in all cases?
> Wait a second-- No, this is only in older branches, it has been > removed since the mhdctmerge forked off, somewhere shortly after Week > Of Code. I'm assuming this should, in fact, be off and [Total > Gas]Energy should be flux-corrected even when radiativeCooling=1
> Thanks, > d.
> On Thu, Dec 15, 2011 at 4:41 PM, David Collins > <dcoll...@physics.ucsd.edu> wrote: > > Hi, all--
> > Several places in the code require a subset of fields to be multiplied > > by density before conservative actions take place. As the code gets > > more complex, this logic has become cumbersome, so I'm replacing it > > with a function, MakeFieldConservative( field_type ).
> > I have two questions for the group.
> > First: I have identified the following routines that require this. > > Are there any others that y'all can think of? > > Grid_InterpolateFieldValues.C > > Grid_ProjectSolutionToParentGrid.C > > Grid_InterpolateBoundaryFromParent.C > > [FluxFix_]Grid_CorrectForRefinedFluxes.C
> > Second: FieldTypeNoInterpolate[] is examined in > > CorrectForRefinedFluxes and ProjectSolutionToParent, but not the two > > interpolation routines, InterpolateFieldValues and > > InterpolateBoundaryFromParent. As the array is called > > "NoInterpolate", this seems like an error to me. I don't fully > > understand this array, could someone comment on this? I looked only > > in the dev branch, hg id=ac7a5dacd12b on the bitbucket/enzo-dev repo. > > This is important as I consider including the check against that array > > in MakeFieldConservative, or, if it's not a condition that needs to be > > checked at each of these instances, there will be two conditionals in > > these conservative transform points.
> > Thanks a ton, > > d.
> > -- > > Sent from my computer.
> -- > Sent from my computer.
> -- > You received this message because you are subscribed to the Google Groups > "enzo-dev" group. > To post to this group, send email to enzo-dev@googlegroups.com. > To unsubscribe from this group, send email to > enzo-dev+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/enzo-dev?hl=en.
