agnwinds / python

This is the repository for Python, the radiative transfer code used to winds in AGN and other syatems
GNU General Public License v3.0
26 stars 25 forks source link

Domains #164

Closed kslong closed 8 years ago

kslong commented 9 years ago

This is an area to discuss how we implement domains in Python. My first efforts on this have not been entirely successful and I think it is a good idea to try to summarize what we want to do and what are the issues associated with this.

We currently store nearly all of the information about a model in python.h. We have a single Wind structure, a single Plasma structure, and a geo structure. Nominally.

geo includes most of what is read in from the command line, and lots of derived quantities such as luminosity and convergence results

wind defines the grid, and contains velocities. The grid covers the entire "space" in which the radiative transfer is calculated.

plasma defines the physical conditions in each grid cell that has volume in the actual wind.

In addiction, python.h contains many derived quantities to facilitate the calculation. These include arrays which are used for identifying where a photon is in the wind. It also contains all of the rest of the structures and a lot of "control" data for the program.

Note that saving the wind, amounts to saving the geo, wind, and plasma structures.

With the addition of multiple components to the wind, e.g the disk layer, we are introducing the concept of a domain, which in terms of the "architecture" of the way we represent space, is at the top of the hierarchy.

Domain --> Wind --> Plasma

There is nominally one element in the domain for each individual structure. So a model consisting of and SV wind and a disk layer would have two Domain elements. Each of those elements would have a set of associated Wind elements, which in turn would have Plams elements.

Domains = 2 Winds = 2 x the number of cells in each domain Plasma = 2 x the number of cells with volume in the domain

One of the issues is how geometry fits into this. The proposed solution is to move those quantities which really describe the domains (e.g. the wind parameters) into the appropriate Domain, and leave those elements which are not domain specific in geo. Some of the ancillary information also needs to be moved into the domains.

The issue of how to set these domains up and easily index into them is one of the main considerations. We always need to be able to determine what wind cell (domain+windcell) that a "photon is located in". There are times we would like to cycle through all of the cells in any of the regions.

There are times when we are concerned only with a single domain; there are other times we are concerned with all of the cells (usually those associated with Plasma), e.g for calculating the emission.

This suggests, we would like to have both a PlasmaMain which points to all of the plasma elements, and ways to map into just the elements for a particular domain. Currently we create elements for each domain. Probably, we can create a Ptr array which stores all of the elements.

Note: python.h is now very complicated, and over 1300 lines long. I think it is time to split it into two files, one with the stuff we want to save to the windfile, and one with everything else.

jhmatthews commented 9 years ago

Quick note so I don't forget- need to be very careful with interpolations on e.g. wmain[n].vgrad now we have multiple domains but one wind structure.

kslong commented 9 years ago

150825 - Current version runs a short sv model, but there are still problems, early on. In particular the number of cells in the wind is different from that obtained with dev.

domain2: wind2d: 900 cells of which 461 are in inwind, 75 partially in_wind, & 536 with pos. vol dev: wind2d: 900 cells of which 238 are in inwind, 99 partially in_wind, & 337 with pos. vol

Note: I just checked what is actually in the windsave file and it looks as if the numbers are the same there. So I do not completely understand this

This problem is related to changes in where_in_wind, which now returns to domain number if a position is in one of the wind areas.

It is not completely clear that we have thought what we want where_in_wind to do. Possibly we want it to return both the domain, and the indication of whether it is inside the appropriate wind cones. The reason we switched to a domain was because we have multiple domains and often want to know which domain we are in.

This particular problem is now solved, as domain2 and dev now give the same number of cells. where_in_wind now returns whether you are in the end or not. An additional pointer to where_in_wind is passed, and this contains the domain.

kslong commented 9 years ago

150825 - The current problem with domain2 is that, although py sv runs, the wind is not absorbing enough photons to keep the atmosphere hot. Although scatterings are occurring, the numbers are much lower than in an sv model run with dev. My guess is that this it has to do with home photons are going through the wind. This may require following individual photons through the wind with the same inputs to dev and to domain.

This problem turned out to be due to the fact that we had not set geo.ndomain, when we were trying to set up the windcones. As a result, there were no windcones. Once this was fixed, the standard sv model ran, an as far as I can tell the results are identical to hose in dev. The is the spectrum produced, the first with this version of python:

sv

kslong commented 8 years ago

Domains are now incorporated into our standard version of pipeline. It seems appropriate to close this now.