simulation of a wind emitting star

[Mniel]

Hi,

I'm completely new to Enzo and have very limited experience with hydro codes in general, so please bear with me. Enzo appears to be a great code with a lot of functionality, and I'm very eager to use it for my research. However, it's also quite daunting (especially for someone with very limited experience with other hydro codes), and I fear it will be hard going without someone to point me in the right direction. So, thanks a lot in advance to anyone willing to lend me a hand!

I would like to use Enzo for a simple, non-cosmological simulation: a star emitting a continuous wind with constant velocity. That's it, nothing too fancy, I think - just a toy model to try out how to modify the code for astrophysical problems (later on, I want to add some additional things to the simulation, e.g. gravity of the wind-emitting star, a compact accretor in binary orbit inside the wind, and radiative transfer in the wind). However, it is not clear to me how to do this; by modifying the SedovBlast problem files a little I've managed to set up a new problem that creates an outgoing density field that is emitted from a central, gravitation-less object at the beginning of the run, and this then expands outwards into a low-density environment in a way that looks reasonably correct to me (i.e. enhanced density at the 'shockwave'-ambient medium interface, lower density behind the 'shockwave'). However, I would like this field to be emitted continuously, not just at the beginning of the simulation. Is there a good way to do this? Have other people done similar things, so that I might look at their modifications for inspiration? For the moment, considering the central star to be gravitation-less is fine, although I may want to make this more realistic later on by adding gravity and radiative pressure from the central star.

Not sure if this topic belongs here on the users group, by the way. Since what I want to do requires changing the code itself rather than just the input params, I concluded that the topic belonged in the dev group, but if I'm wrong please let me know and I'll take my question to the users group instead.

Cheers.

[Brian O'Shea]

Hi,

Welcome to the Enzo community!  This is the correct venue for help, though I would note that you can also go to the #enzo channel on irc.freenode.net - there's often somebody around that can help out a bit.

If you are only going to have a single star/particle acting at a time, which will be at a fixed position on the grid, your best bet is probably to add a routine to EvolveLevel.C that manipulates the grids directly.  I would start by looking at Grid::StarParticleHandler (in Grid_StarParticleHandler.C), which is called from line 563 in EvolveLevel.C, and also one of the problem initialization routines that manipulates grids in a position-dependent way (Grid_SedovBlastInitializeGrid.C is a good example of this, although it only works in 2D;  Grid_RadiatingShockInitializeGrid.C is a much more complex example that works in 3D as well).  StarParticleHandler is actually a much more complex routine than you need - it's built to let the user choose between many different star formation and feedback routines, and calls fortran code, which you do not need to do.  However, I mentioned it because you'll want to make a call to a new routine at roughly the same place in EvolveLevel, and which looks the same (and which is also a Grid routine).  Inside that routine you're going to want to have your time- and position-dependent feedback, manipulating the grid in a way similar to how  Grid_RadiatingShockInitializeGrid.C does it.

I would note that you probably want to look through the Enzo Developer's Guide (https://enzo.readthedocs.org/en/latest/developer_guide/index.html) - in particular, the "Accessing Data in BaryonField" section and the "Adding a new Test Problem" section (the latter is important since you'll need to modify a variety of places in the code and in the makefile system).  Another potentially useful piece of the docs include the section on Enzo's internal unit system (https://enzo.readthedocs.org/en/latest/reference/EnzoInternalUnits.html), which is logical and self-consistent, but not necessarily transparent to the newcomer.  

I appreciate that this is somewhat general advice - if you want to experiment a bit and contact the list again, please don't hesitate to do so.  You may want to create a BitBucket account and fork enzo-dev - if you do that, you can push changes to your BitBucket fork and we can look at it and give you suggestions pretty easily.

Regards,

Brian

--
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.
For more options, visit https://groups.google.com/d/optout.

[Mniel]

Hi Brian,

Thanks very much for your helpful and impressively rapid response! I'll follow your suggestions and see if I can make it work.

Cheers!