Opened 7 years ago

#191 new defect - convergence

BLR sim not fully converged

Reported by: Gary J. Ferland Owned by: nobody
Priority: major Milestone: C13 branch
Component: ionization convergence Version: trunk
Keywords: Cc:


The BLR sims use the "iterate to convergence" command to control convergence. The sim blr_n11_p20_Z20 obtained different results when trivial changes in the source were made. This is due to the "iterate to convergence" logic stopping before the sim was actually converged.

r4493 increased the error. The emails discussing the problem are in the input script, and are pasted below

2010 dec 25
This sim obtains different results for Hb and Fe II with gcc and icc.  This is because the
sim is not fully converged.  Robin's & Peter's notes follow.  This will probably be trac ticket #191

results changed with trivial changes in the source - Peter's example follows;
This is due to lack of convergence rather than a fundamental difference in physics

 Fe 2  2400A   6.854   1.9161
 Fe 2  6200A   6.827   1.8005
 Fe 2  2500A   6.984   2.5834
 Fe 2  2300A   7.101   3.3854
 Fe 2  8900A   6.714   1.3899


 Fe 2  2400A   6.852   1.9092
 Fe 2  6200A   6.923   2.2472
 Fe 2  2500A   6.943   2.3504
 Fe 2  2300A   7.161   3.8897
 Fe 2  8900A   6.671   1.2574

OK, I ran for 10 iterations with an old vs. new test on the cooling --
no substantial differences were reported.

The ne does seem to wander around quite a bit deep in the model,
rather than smoothly converge -- attached plot is for the last
iterations 5 to 10 (i.e. from when the code declares convergence in
the standard blr_... run onwards).  Not so bad as the difference plot
which Peter shows, but not great.  The temperature convergence seems

Suggests to me this may be a problem with poor convergence
criteria/hysteresis, with the collisional cooling change just being
the butterfly.

there's also an unresolved drop in both ne and H+ around 8.5e11
cm in the first iteration, which might be worth trying to understand.

It looks like there is a small thermal front in this model near the 
outer edge, though I derive this only from eyeballing the Te plot. 
They are quite common in blr models. It would also be a partial 
explanation of the jerky behavior of the code: gas near such a 
front will be quite sensitive to changes in cooling and/or heating 
since the curves are nearly parallel. It is however still
worthwhile asking whether we are exacerbating the problem by
writing the cooling terms in atom_leveln() the way we do.

Yes, there is a temperature front exactly at the rear of the slab (it
only appears in the later iterations).

email exhange on this was around 2010 dec 22 - 24 

Change History (0)

Note: See TracTickets for help on using tickets.