Rad hydro notes
Attached to this blog post is my notes on Krumholz+2007
Wind-Clump interactions
I ran a series of numerical experiments to get a feel for how things like magnetic diffusion, cooling, field orientation might affect the results of the setup shown here (B-field is parallel to wire obstacles - into the board (z direction)). Cases with Diffusion have a diffusion scale length of .3 cm - and anything that says Tiny Diffusion uses a diffusion length scale of .01 cm. I also ran a few cases where the field is inclined - so By = .1*Bz
Left panel is density more or less scaled to final max density. Right panel is Bz autoscaled Cases with non-zero By field show contours of the vector potential that trace the field.
Dust in AstroBEAR - Update 2020/11/23
Very short post this week:
Good News:
I've compared my intermediate and end results per cell/bin/timestep with the external dust processing code and they match up. Meaning I get the same rates for dust advection/destruction!
Bad News:
It seems that for the Spitzer Plasma Drag and the Grain-Grain Collisions the rates with which the dust densities change from one timestep to the other are too large and AstroBEAR crashes with a "minimum timestep"-error…. not sure what to do here, would be great to discuss a bit.
CEJet figures
Bound vs. unbound energy with density contours:
Frames in each row are chosen as:
- 1st periastron
- 1st apastron
- 2nd periastron
- ~ 30 days (periastron for runs 6, 10, 11; and apastron for runs 13, 14)
- ~ 35 days (periastron)
Run 06, normal jet
Run 10, super jet
Run 11, no jet
Progress as of 19 November 2020
These first plots are taken from one-dimensional runs. These plots trace the position of the shock front as it moves through time. The red curve is taken as the point of maximum temperature, while the blue curve is taken as the point of steepest increase in the logarithm of density. On the right of each of these is the Fourier transform of the temperature plot. In cases where the temperature is constant throughout (which occurs if the shock isn't fully resolved; this only seems to occur for negative values of beta) the peak temperature location is taken to be the location of the previous peak.
It should be noted that there are usually two regions of high density increase; the forward of which usually coincides with temperature peak while the rear usually coincides with the point where temperature returns to the ambient value. The steeper of the two is usually, but not necessarily, the rear. This explains some of the sharp oscillations observed in the higher values of beta as the front gradient becomes as steep as the rear.
Beta | Position | Fourier Transform |
---|---|---|
-1.0 | ||
-0.5 | ||
0.0 | ||
+0.5 | ||
+1.0 | ||
+1.5 | ||
+2.0 | ||
+2.5 | ||
+3.0 |
These next sets switch to three dimensions, all using Beta=0 (constant cooling function). From left to right, the (estimated) cooling length is set to be approximately equal to five jet radii, one jet radius, half the jet radius, one fourth, and one eighth.
And another projection along the jet axis
Currently I am conducting runs with varying Beta, using the same value of alpha that produced the cooling length equal to five jet radii and all of the values of beta that were used in the one-dimensional runs. These runs are also conducted over a larger area. So far I have preliminary results for Beta=1 (Left) and Beta=2 (Right)
HEDLA Jet meeting 11/20/2020
summary | |
frame12; setup 2 By=1 boundary-run;setup 2 By=1 clump-run; |
1. Setup 1
setup1 |
Box: 160x160 mm radius_wire = 2 mm distance_between_centers = 9 mm MagField_direction = 0, 0, -1 rhoWire = 2.86e19 g/cc tempWire = 1.39e3 K WindMaterial = 27 rhoWind = 2.86e+17 1/cc velWind = 6e1 km/s BWind ! varies see table TempWind = 12 ev or 1.39e5 K rhoAmb = 2.86e+17 1/cc tempAmb = 1.39e5 K velAmb = 6e1 km/s dx: 0.3125mm runTime: 4.92 ms or 1.8 domain crossing time or 32.8 wire distance crossing time.. imomentumProtect=1
Runs | Results | diffusion parameter |
hydro, no cooling | rho;Temp;mach; | 2 |
hydro, Al cooling | rho;Temp;Mach; | 2 |
Bz=0.1T, beta=138, no cooling | rho; Temp; Mach; mag pressure; | 2 |
Bz=0.1T, beta=138, Al cooling | rho; Temp; Mach; mag pressure; | 2 |
Bz=1T, beta=1.38, no cooling | rho; Temp; Mach; mag pressure; | 1 |
Bz=1T, beta=1.38, Al cooling | rho; Temp; Mach; mag pressure; | 1 |
Bz=5T, beta=0.055, no cooling | rho; Temp; Mach; mag pressure; | 1 |
Bz=5T, beta=0.055, Al cooling | rho; Temp; Mach; mag pressure; | 1 |
2. Setup 2
setup2 |
Box: 20x20 mm radius_wire = 0.25 mm distance_between_centers = 7.5 mm MagField_direction = 0, -1, 0 rhoWire = 2.86e19 g/cc WindMaterial = 27 rhoWind = 2.86E+17 1/cc velWind = 6e1 km/s BWind !varies see table TempWind = 12 ev or 1.39e5 K dx: 0.03125mm runTime: ~90ns (0.924 ms) or ~0.4(3.6) domain crossing time, or ~1 (9.6) wire distance crossing time imomentumProtect=1
Runs | Results | diffusion parameter |
hydro, no cooling | rho;Temp;mach; | 2 |
hydro, Al cooling | rho;Temp;Mach; | 2 |
By=0.1T, beta=138, no cooling | rho; Temp; Mach; mag pressure; | 1 |
By=0.1T, beta=138, Al cooling | rho; Temp; Mach; mag pressure; | 1 |
By=1T, beta=1.38, no cooling | rho; Temp; Mach; mag pressure; | 1 |
By=1T, beta=1.38, Al cooling | rho; Temp; Mach; mag pressure; | 1 |
By=5T, beta=0.055, no cooling | rho; Temp; Mach; mag pressure; | 1 |
By=5T, beta=0.055, Al cooling | rho; Temp; Mach; mag pressure; | 1 |
3. Setup 3
setup3 |
Box: 20x20 mm radius_wire = 0.25 mm distance_between_centers = 3.0 mm MagField_direction = 0, 0, -1 rhoWire = 2.86e19 g/cc WindMaterial = 27 rhoWind = 2.86E+17 1/cc velWind = 6e6 cm/s BWind ! varies see table TempWind = 12 ev or 1.39e5 K rhoAmb = 2.86e+17 1/cc tempAmb = 1.39e5 K velAmb = 6e1 km/s dx: 0.3125mm runTime: 0.924 ms or 3.6 domain crossing time, or 9.6 wire distance crossing time imomentumProtect=1
Runs | Results | diffusion parameter |
hydro, no cooling | rho;Temp;mach; | 1 |
hydro, Al cooling | rho;Temp;Mach; | 1 |
Bz=0.1T, beta=138, no cooling | rho; Temp; Mach; mag pressure; | 1 |
Bz=0.1T, beta=138, Al cooling | rho; Temp; Mach; mag pressure; | 1 |
Bz=1T, beta=1.38, no cooling | rho; Temp; Mach; mag pressure; | 1 |
Bz=1T, beta=1.38, Al cooling | rho; Temp; Mach; mag pressure; | 1 |
Bz=5T, beta=0.055, no cooling | rho; Temp; Mach; mag pressure; | 1 |
Bz=5T, beta=0.055, Al cooling | rho; Temp; Mach; mag pressure; | 1 |
sample data files | global.data;physics.data; solver.data; scales.data; problem.data |
Documents from Danny
In the table each column represents a different simulation. The parameters in dark blue are dimensions and simulation setup instructions. The parameters in light blue are experimentally measured parameters for the plasma and obstacle. The rest of the parameter (white) are calculated using formulars from refs 1 and 2. There is a separate power point with the setup images which shows the layout of the obstacles and the direction of the magnetic field, the relevant figure is referenced in cell 5. The first two simulations we are interested in are a comparison of the same initial setup with and without radiative cooling. In our experiments we observe that the plasma temperature does not drop much below 12eV. However, a calculation of the cooling time suggests that within our experimental time frame we should see cooling. This could be due to a heating mechanism, such as ohmic heating. We are therefore interested to know whether a simulation with a realistic cooling time or one with no radiative cooling at all better resembles our data. The cooling time I have suggested for simulation 1 is taken from the Al cooling curves presented in ref 3 using the ni, Te and Z ̅ values shown in the table. For simulations 2 I have suggested the same experiment with no radiative cooling. The experimental setup is one that we have used several times and have very good data for. Once we see the results from these two simulations we will have other suggestions but we would like to understand the roll of radiative cooling in the simulations first.
Simulations requests for AstroBEAR | ||
Simulations requests for AstroBEAR | Figures for AstroBEAR simulations | Notes on simulation suggestions for AstroBEAR |
Update 11/16
Pathways Proposal
Deadline was extended to this Friday (I get the impression that they feel Frontera is underutilized so far), so taking the opportunity for a few quick questions:
Fields:
120 - Astronomical Sciences (Primary) 510 - Atmospheric Sciences (Secondary) 130 - Physics (Secondary) 122 - Planetary Astronomy (Secondary)
Jonathan: University Research Staff or Faculty?
Grants: So far I've included the DoE grant, but it's MHD-focused, so maybe just barely fits the criteria: "Is the proposed work supported by a grant or grants that have undergone review for intellectual merit and/or broader impact (if relevant to the allocation)? If so, is the allocation request consistent with the objectives of the supporting grants and is the scale of resource use commensurate with the level and purpose of support?" and "the stated scientific objectives must match or be sub-goals of those described in the listed funding award(s)". Could perhaps describe as a sub-goal. Don't think we can include the NSF grant at all, based on this.
Charge exchange
Three more frames with startup allocation, but only have 103 node-hours left, so definitely can't get any more frames with it. May try to do some profiling if I have time. Here's the current state:
Update 11/9
Note of fun - the simulation is surprisingly robust to a large empty cube suddenly appearing in the center of the planet.
Frontera Proposal
Strong scaling test is done for 8-128 nodes. It looks like the proposal should be a single document, so I've combined the scaling document and the previous supplement main document. Still needs a little work, but I'll try to send it around by end of day for review.
One sticking point: the steady-state run is about 12 times faster than the current state of the simulation. How to best request the appropriate number of hours? Pathways allocations are meant to help with scaling up to make better use of Frontera (see description below) - perhaps frame single run as test case for larger request that combines both charge exchange and radiation pressure (and B fields?)? And possibly profiling time? Would still like to see if the line transfer can be improved.
Pathways
Experience suggests that not all user teams can seamlessly make the transition from more general-use resources, such as Stampede2, to a system that emphasizes larger scale computing. It is here that latent scaling bugs (such as race conditions, hard-coded array bounds, and so on) are often encountered for the first time. The “Pathways” allocations track is for projects that believe they are ready to begin scaling up, but have not yet fully tested their applications at scale. Less stringent scaling data will need to be provided to receive a pathways allocation, and the total award size will be smaller, with a focus on preparing to reach the LRAC scale.
Here's the statement of requirements, for reference:
Proposal Format
LRAC, Pathways, and LSCP Submissions Requests
When writing your LRAC request, be clear and concise. We strive to have domain experts review every request, but they may not have deep expertise in your specific subdomain. Someone outside of your area should be able to understand the scientific objectives and understand why the chosen technique is preferred over another.
Renewal requests require less documentation, as described later (jump link to section).
The documents required of a new LRAC request ensures reviewers can effectively determine how each request satisfies the Frontera allocation Review Criteria. LRAC requests are limited to 10 pages.
Research requests must include a well-documented resource-use plan that describes how the requested allocations are necessary and sufficient to accomplish the project’s research objectives. An effective resource-use plan must address the Frontera allocation Review Criteria and, in particular, must include the following elements:
Scientific Background Research Objectives and specific questions to be pursued Resource Usage Plan to achieve the research objectives Justification of the allocation amounts for all resources and resource types Access to other CI resources and why those resources are not available or sufficient for the work proposed in this request
Scientific Background and Support
Succinctly state the scientific objectives that will be facilitated by the allocation. The existing merit-reviewed supporting grants should be listed and briefly described; please include the end date for each grant listed. Requests with merit-reviewed supporting grants will not be subject to further scientific review by the LRAC; however, the stated scientific objectives must match or be sub-goals of those described in the listed funding award(s). The description of the objectives should be sufficient to allow the reviewers to assess the resource usage plan.
Research Questions
Identify the specific research questions that are covered by the allocation request. Within the context of the scientific background and supporting grants, these objectives and questions should be stated so that the reviewers can understand how elements of the resource plan will contribute to relevant answers. If you consider the allocation request in terms of computational experiments, the research objectives and questions define the experiments to be conducted.
Resource Usage Plan
The bulk of the document should focus on the resource usage plan and allocation request. Inadequate justification for requested resources is the primary reason for most reduced or denied allocations. Once again, the PI should keep in mind the Frontera allocation Review Criteria when describing and justifying the choice of resources and allocation amounts.
Justifying Allocation Amounts
This section should contain code performance timings, resource usage details, and scaling information to support the calculation of the resource request. Ideally, the code performance data should be provided from benchmark runs on the resource requested, using the model configuration(s) needed for the computational plan proposed and demonstrating the scaling efficiency to the job size(s) planned. If applicable, the panel may accept well-justified performance data from architecturally equivalent systems. PI’s should contact the Frontera Allocations Coordinator to obtain a small allocation for benchmarking or to discuss non-Frontera performance data to be used in their submission.
The justification of allocation should take the quantitative parameters from the resource usage plan and combine them with benchmark cost information to calculate the allocation needed. Where possible for computational experiments, the justification should tabulate and calculate the costs of conducting each experiment for each resource and resource type.
Disclosure of Access to Other Compute Resources
Because of the high demand for NSF-funded resources, Frontera and the LRAC closely consider whether the PI has access to other, less constrained resources on which the proposed work could be conducted. All PIs must describe their local resources and other non-Frontera resources available to them, including both local and other national resources.
Page limit: 10 pages
References
[Note: probably unnecessary]
A PI may use this OPTIONAL document to separate a lengthy bibliography of cited work to take full advantage of the page limits in the Main Document. This bibliography is not the publications resulting from prior Frontera support, which should be entered into the Frontera publications database, but rather other citations referenced in describing or supporting the intellectual merit of the proposed work or the appropriateness of the proposed approach for addressing the research objectives.
Page limit: No limit.
Document Formatting
While readability is of greatest importance, documents must satisfy the following minimum requirements. Documents that conform to NSF proposal format guidelines will satisfy these guidelines.
Margins: Documents must have 2.5-cm (1-inch) margins at the top, bottom, and sides. Fonts and Spacing: The type size used throughout the documents must conform to the following three requirements:
Use one of the following typefaces identified below:
Arial 11, Courier New, or Palatino Linotype at a font size of 10 points or larger; Times New Roman at a font size of 11 points or larger; or Computer Modern family of fonts at a font size of 11 points or larger.
A font size of less than 10 points may be used for mathematical formulas or equations, figures, table or diagram captions and when using a Symbol font to insert Greek letters or special characters. PIs are cautioned, however, that the text must still be readable.
Page Numbering: Page numbers should be included by the submitter.
Meeting update
- Frontera Pathway proposal due this week. Working on weak scaling test.
- MHD outflow clumps: Fixed the high-density tail issue. Needs suggestion/comments for the MHD runs.
Varying Cooling Length
All of these runs use Beta=0, which corresponds a constant cooling function. From left to right, the (estimated) cooling length is set to be approximately equal to five jet radii, one jet radius, half the jet radius, one fourth, and one eighth.
And another projection along the jet axis
UPDATE 11/06: added cooling length = 5 Jet Radii
Dust in AstroBEAR - Update 2020/11/02 & 2020/11/09
Objectives
- Debugging
Progress:
Gas Drag: Did more benchmarking of intermediate calculation steps and they all look fine so still not sure what's going on. I also ran the simulations discussed last time:
- no wind, just a clump with initial velocity in x → looked fine, did not see the same effect as in the wind+drag simulations
- Fixed temperature to check the temperature dependence → that's noticeably different. Made a couple of videos: 1. Normal temperature dependence, 2. Fixed high temperature (around 2E8K), 3. Fixed medium temperature (around 2E6K), 4. Fixed low temperature (around 2E4K). To summarise: Movement looks fine for large T (though I suspect the drag force is still too strong), the movement looks very strange for small T. For small T is looks like the attraction between charged ions in the wind and charged dust grains is so large, that the grains are sucked towards the wind. Potential error sources here: Faulty gas ionisation degree (have checked this before but will again just in case), maybe T is off, drag force too strong, something else? (made a couple of screenshots for the low T case as well with more output steps: 1 2 3 4 5 6 7
Grain-Grain Collisions: Made quite a bit of progress here, found a lot of smaller errors and the routine now works (previously it crashed because the collision probabilities exceeded 1) but I'm gaining mass here as well just as with the sputtering routine. → Will check the routine which sorts the grains into bins next, if mass conservation is broken, it's most likely because something goes wrong in there. UPDATE: Might have found the bug here, still needs testing but hoping to show some first simulations next week.
Next steps:
- Continue debugging