-
Notifications
You must be signed in to change notification settings - Fork 0
Beefs_and_bugs
Time-dependent runs with reconnection occasionally crash-and-burn. Problems with memory allocation? drzowie 15:06, 28 January 2009 (MST)
A related observation: runs that involve reconnection are not exactly reproducible. They give slightly different answers each time. It is not yet clear whether that is due to reconncetion not being reliable, or to memory not being treated correctly in some way. My money is on the latter, since that would also explain the crash-and-burn problem.
- IWBNI the curvature force had the next higher order term(s) in the small angle approximation to sin(theta), to minimize loop size effects from vertex count.
- the locale_radius isn't saved. Specifically concentration->locale_radius, but possibly the others as well.
- neither is the concentration boundary condition
Fixed: CVS Oct 2009. New format for the NEW line includes optional locale_radius and boundary condition options.
Generally this happens with large worlds, but not exclusively. There is a world variable, $w, and you relax the world, but you want to use that variable name again. So you 'undef $w', and say $w=str2world() or something like that. occasionally you get a bunch of warnings like 'WHOA THERE! doomed vertex 1882741532's nearby 413046721 had no neighbor link back!' and then a seg fault.
This also sometimes happens if you simply exit out of pdl and you have an active world.
Possible fix: pushing $w onto an array before you undef it.
Fix: the problem was with reference counts. It has been fixed.
Sometimes the last-but-one vertex on a fluxon would "freeze" and accumulate large forces, coming to dominate the overall sim. That was because it was interacting with its image through the photosphere, giving it an r_cl of 10^-17 or less (double-precision roundoff). Since motion is scaled according to the closest-approach neighbor, the vertex would get frozen. The solution is to prevent the first or last segments of non-plasmoid fluxons from interacting directly with image fluxels. drzowie 15:04, 28 January 2009 (MST)
- Relaxations are not exactly reproducible -- multiple instances of FLUX yield slightly different answers for the same initial conditions.
This may be related to the "breakdown" errors that we occasonally see in time-dependent sims. It appears that some memory may be used without initialization, but the code is probably stable enough to recover in all but an infinitesimal number of cases. drzowie 13:34, 28 January 2009 (MST)
Investigation:
- Does not appear in the menagerie/potential.flux system (!)
- does appear in the tiny-photosphere simulations in the fluxon-corks investigation...
- is not dependent on reconnection: even frame 0 of the fluxon-corks drifts apart.
- may be due to a random element in corksdump2flux: I'll try two relaxations of the same exact initial sim...
- is due to the random element in corksdump2flux: relaxing the same initial condition twice yields exactly the same answers.
-
- Energy increases then decreases in the twisting open-flux simulations (is this due to open Voronoi cells? or to problems with fluxel length compensation?)
- Energy increases during relaxation in some systems
-
- Present solution is to try to re-index fluxon labels in input (.flx) file, but long term adjustments to FLUX code may be preferable
- See my RunsOfFLUX page 1 with some of the data/errors from my FLUX runs for more info
Fixed -- the problem was the autocreation of end vertices for newly read fluxons in io.c: autocreated end vertices have negative values based on the fluxon's id number by a simple formula. Extended the formula to not include the range -1 -- -10. drzowie 09:47, 18 July 2008 (MDT)
-
- Some systems are reported to get less accurate (in the sense of having correct field angles) as they relax.
- This seems to be a case of symmetry breaking: initial relaxations of highly symmetric cases tend to go through twisted metastable states when the symmetry breaks (e.g. the potential field demo).
-
- This should be fixed now with f_pressure_equi2b; needs to be run through the MSU validation suite
-
- The current boundary conditions artificially set the field to be perpendicular to the photosphere everywhere. That is not right! Charles pointed out that we should be able to eliminate the image fluxels for the first and last fluxel on each fluxon, thereby eliminating the problem. That should be simple but remains to be tried.
- Fixed: Yup, I added a mask that prevents the end fluxels of line-tied fluxons from interacting with the image fluxels. That seems to work just fine -- qualitatively, field lines enter the photosphere at approximately the same angle that they approach it from afar, so this is a reasonable short-term fix. It isn't an exact solution -- the last segment "wants" to go under the photosphere, and is prevented only by the combination of the curvature force at the first nontrivial vertex and the pressure force on the first non-endpoint segment -- but at least that is a much better approximation than normal incidence.
-
- The new vertex distribution pseudoforce caused problems in Montana
- When Laurel uses the new vertex pseudoforce that distributes vertices along the fluxon it causes the system to hairball in a few instances: generally it is the last fluxon that has problems, and it is only when that fluxon has too few vertices. So far, fiddling with the scalar parameters in front of each of the vertex pseudoforces hasn't yielded the correct combination.
These problems happened because the vertex pseudoforce didn't scale properly with distance (ie not the same way as the other force law components). The current pseudoforce, f_vertex4, seems to solve that problem. drzowie 14:55, 27 September 2007 (MDT)
Fix_curvature caused problems on vertex removal, due to some bookkeeping errors in the unlink_vertex routine. Those appear to be fixed now in the current CVS. I wrote a simple verifier, neighbor_check in the PDL side, that can be used to verify correctness of the neighbor linking structure. It is in .../flux/pdl/PDL/neighbor_check.pdl. drzowie 14:57, 27 September 2007 (MDT)
For at least some runs of FLUX, virtually every line displays something like the first error on this page 2
-
- This is probably due to lines crossing at some point
- This can become a major problem in more complex simulations
This appears to be harmless but I will look into it more over the weekend (hopefully) drzowie 18:02, 17 July 2008 (MDT) I think this was resolved a while ago; will retire it shortly.