Presentation is loading. Please wait.

Presentation is loading. Please wait.

Optimization_fff as a Data Product J.McTiernan HMI/AIA Meeting 16-Feb-2006.

Similar presentations


Presentation on theme: "Optimization_fff as a Data Product J.McTiernan HMI/AIA Meeting 16-Feb-2006."— Presentation transcript:

1 Optimization_fff as a Data Product J.McTiernan HMI/AIA Meeting 16-Feb-2006

2 Optimization method: Wheatland, Roumeliotis & Sturrock, Apj, 540, 1150 Objective: minimize the “Objective Function” We can write: If we vary B, such that dB/dt = F, and dB/dt = 0 on the boundary, then L will decrease.

3 Optimization method (cont): Start with a box. The bottom boundary is the magnetogram, the upper and side boundaries are the initial field. Typically start with potential field or linear FFF, extrapolated from magnetogram. Calculate F, set new B = B + F*dt (typical dt =1.0e-5). B is fixed on all boundaries. “Objective function”, L, is guaranteed to decrease, but the change in L (ΔL) becomes smaller as iterations continue. Iterate until ΔL approaches 0. The final extrapolation is dependent on all boundary conditions and therefore on the initial conditions. Requires a vector magnetogram, with 180 degree ambiguity resolved.

4 Optimization method Idl code: Online as an SSW package, see http://www.lmsal.com/solarsoft/. Slow, a test case with 64x64x64 cube took 157 minutes (3.2 GHz Linux processor 4 Gbytes RAM) (Currently I am committed to writing Fortran version, should pick up a factor of 5 to 10? T.Wiegelmann’s code is faster.) Users can specify 2d or 3d input, and all spatial grids. Spatial grids can be variable. Code can use spherical coordinates. (But, /spherical has no automatic initialization – so the user needs to specify all boundaries. Also /spherical is relatively untested.) Uncertainties? Some tests (See S.Solanki talk from this meeting, J.McTiernan SHINE 2005 poster.) These will have to be characterized, to get a uncertainty as a function of height, and field strength in the magnetogram.

5 Speed test #1: 64x64x64 cube, used Low-Lou solution, potential extrapolation for initial field, side and upper boundaries: Total time = 157 min Per iteration = 3.06 sec 32x32x32 cube, same Low-Lou solution, potential extrapolation for initial field, side and upper boundaries: Total time = 10 min Per iteration = 0.32 sec So Per iteration, time scales as N 3 (or N T ) Total time scales as N 4 (or N T 4/3 )

6 Speed test #2: 115x99x99 cube, AR 9026 IVM data, potential extrapolation for initial field, side and upper boundaries: Total time = 67 min Per iteration = 6.43 sec 231x198x41 cube, AR 9026 IVM data, potential extrapolation for initial field, side and upper boundaries, variable z grid : Total time = 95 min Per iteration = 10.5 sec Per iteration, time still scales as N T Total time scales as less than N T ? Fewer iterations, and larger final L value for variable grid case…

7 Memory: Memory usage is not a problem, in comparison to speed. Memory usage will scale with N T. Typically, you have 7 three-D arrays held in memory: For 3 components of B, 3 components of J, and div B. For the 115x99x99 cube, this is 31 Mbytes (7*4 bytes*N T ) For a 512x512x32 cube, this is 58 Mbytes. For a 512x512x512 cube, this is 3.76 Gbytes

8 In the pipeline? Say you want to provide extrapolations as a data product, and that the code is a factor of 10 faster than this one, so that it takes 6.7 min to do the 115x99x99 cube, and that processing time scales as N T 4/3. Say that there are 5 AR’s, and we have 512x512 boxes containing each one. A 512x512x32 extrapolation takes approximately 97 min. Is 1 extrapolation per AR per day an option? If you want a large-scale extrapolation, for as large a chunk of the sun that you have ambiguity resolution, but with reduced spatial resolution (5 arcsec?) – maybe 200x200x200, scaled to so that the solution reaches 2.5 solar radii. This would take 91 minutes. Maybe 1 of these per day.

9 In the pipeline? Now we have 6 extrapolations. Depending on how many CPU’s are available to be dedicated to this, it’ll take about 90 minutes to 9 hours to process 1 day of data. Nine hours is too long, so for this plan to work, so 2 or 3 CPU’s are needed. If the code can be parallelized, maybe this can be made to run faster.

10 Conclusions? We would be happy if we could get 1 extrapolation per day per AR plus 1 larger-scale extrapolation. Or maybe a few large-scale extrapolations per day, and forget about individual AR’s. Tools for extrapolations should be provided to users.

11 Fig 1: Photospheric magnetogram, AR 10486, 29-OCT-2003 1712 UT (from K.D. Leka) Chromospheric magnetogram, AR 10486, 29-OCT-2003 1846 UT (from T.R. Metcalf) BxBy Bz BxByBz

12 Fig 2: Field extrapolations, via optimization method (Wheatland, Sturrock, Roumelotis 2000) Top: Photospheric Bottom: Chromospheric

13 Fig 5: Average fractional uncertainty in the extrapolated field, assuming uncertainty of 100/50G in chromospheric Bxy/Bz and 50/25 G in photospheric Bxy/Bz, from a monte carlo calculation:


Download ppt "Optimization_fff as a Data Product J.McTiernan HMI/AIA Meeting 16-Feb-2006."

Similar presentations


Ads by Google