Learning about sinks in astrobear

Working on understanding sink implementation in the code.

Here is a running dialogue on what I am learning and questions that I have.

The Problem -

1) Currently, the BC's for sinks seem to be set to extrapolating, which is why the sink can move off of the grid… and into the ghost region. Q) Can sinks in the ghost region interact with gas/sinks in the grid?

2) If made them reflecting, once sink would hit the boundary, it would stay at the boundary (since all momenta would be equal and opposite at that point). Q) What are potential negative effects to treating problem this way when there are multiple sinks?

3) How to modify accretion when the sink interacts with reflecting boundary?

Code -

1) amr_control.f90

In Line 266 of AMR_control.f90, in the subroutine LevelsInit, SinkParticleInit is called which lives in Particle_control.f90:

a) SinkParticleInit used for initializing a sink from a problem module — there is a warning about periodic BC's and potential accretion troubles here that I'd like to understand better.

Then on line 473, in Recursive Subroutine AMR(), call ParticlePreUpdate, which

a) clears particle momenta for level n (dmom is an (maxdepth (set=16 in globaldec) x 3 ) array defined in pointgravitydef, px, py, pz, b) If you're on the finest grid (n == maxlevel), then moments are calculated and synch'ed, c) check for new sinks and add any you find to the particle list, d) update accretion for the sinks.

Line 474 calls ApplyPhysicalBCs, then next is ellipticBCs Then we advancegrids (line 530)

Then we call ParticlePostUpdate, which

a) if lsinks, synch's gas forces for particles on each level, and advances particle if on finest level. if lparticles, and on finest level, calls UpdateParticleObjects. Q) What are these handles, lparticle and lsink?

ADVANCE PARTICLE SUBROUTINE -

a) begins by allocating arrays for velocity, position, mass, gas_accel, sink_accel, lfixed (not sure what this is) for each particle, b) next populates arrays from particle%Q(imom(i:ndim)), particle%xloc(1:ndim), etc. Q)How does imom array get filled? Considering adjacent cells? Boundary cells also?, c) next it updates the velocity array using sink_accel by using what appears to be a mean acceleration*dt — vel = vi + dv/dt*(½)*dt. How it computes sink_accel is the matter of GetGasAccel and CalcSinkAcc — so want to check these routines for the potential of boundary effects.

UPDATE PARTICLE OBJECTS -

In this subroutine (here on SR) in particle_control.f90, an associated particle's velocity, position, time, and mass is updated. What I think we are interested in modifying here is the particles velocity (momentum it seems, so why called v?), which as can be seen in this SR goes like:

Particle%PointGravityObj%v0(1:nDim)=Particle%q(imom(1:nDim)) — here, does the array imom contain momentum from ghost cells?

Questions -

1) How to get a center, stable, accreting sink in an octant simulation with AMR?

2) Does each sink have a surrounding mesh separate from the numerical domain?

3) Does a sink form first at a cell center, but then is unrestricted to r? Yes.

4) What are the order of steps? Hydro, source updates (here included are the sinks in particle list), elliptic? Why sink between hydro and elliptic? Where do pre and post update fit into this order?

5) What is n's range? N is the patch level. It runs from -2 to max level of AMR. -2 is the "container" for the info node, -1 is the domain (can have many domains in astrobear1.0, but not implemented in astrobear2.0), 0 is course, and 1 + correspond to the different amr levels. Info nodes -2 and -1 do not contain data structures.

Comments

No comments.