#68 closed defect - convergence (fixed)
ionization convergence problem on second iteration
Reported by: | Gary J. Ferland | Owned by: | nobody |
---|---|---|---|
Priority: | major | Milestone: | c13 release |
Component: | ionization convergence | Version: | |
Keywords: | Cc: |
Description (last modified by )
update on this problem. The attached fast.in will show the problems very quickly. The sim is a static sphere so Lyman lines are strongly trapped - excited state photoionizaiton is the main exit. This comes into the level solver as a destruction probability.
At the end of the iteration the code sets all destruction probabiliries to zero. It is then so far from a solution that it simply cannot find one.
The solution is to save the full state of all the lines at the start of the first zone then recover this state (except for the total line optical depths) at the start of a new iteration.
===================================================== Sim is fast on first iteration, takes nearly forever on second iteration. The iterations take a long while to converge zone 0, then seem to run smoothly thereafter.
g++ profile follows. Recent grain and iso-level routines seem to take a lot of the time:
Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls Ks/call Ks/call name 30.63 1083.91 1083.91 308190728 0.00 0.00 y2s(double, double, long, double*) 21.96 1861.05 777.14 1044319826 0.00 0.00 Yfunc(long, long, double, double, double, double, double, double*, double*, double*, double*) 10.41 2229.52 368.47 1531872 0.00 0.00 UpdatePot1(long, long, long, long) 3.60 2356.83 127.31 448491 0.00 0.00 iso_level(long, long) 3.39 2476.68 119.85 183952 0.00 0.00 iso_cascade(long, long) 2.34 2559.55 82.87 68663 0.00 0.00 RT_OTS() 2.04 2631.65 72.10 390665078 0.00 0.00 atom_level2(t_transition*) 2.00 2702.27 70.62 69949 0.00 0.00 RT_line_all(bool, bool) 1.79 2765.74 63.47 25941714 0.00 0.00 GammaK(long, long, long, double) 1.66 2824.35 58.61 4051117 0.00 0.00 iso_cool(long, long) 1.44 2875.21 50.86 37310808 0.00 0.00 DGER(long, long, double, double*, long, double*, long, double*, long) 1.32 2921.94 46.73 46074 0.00 0.00 RT_line_driving() 1.18 2963.71 41.77 68663 0.00 0.00 CoolDima() 1.15 3004.30 40.59 642708891 0.00 0.00 RT_line_one(t_transition*, bool, bool, bool) 1.11 3043.55 39.25 234524347 0.00 0.00 RT_line_static(t_transition*, bool, bool)
Attachments (3)
Change History (12)
Changed 9 years ago by
Attachment: | testexectime.in added |
---|
Changed 9 years ago by
comment:1 Changed 9 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 9 years ago by
Description: | modified (diff) |
---|
comment:3 Changed 9 years ago by
Component: | grains → ionization convergence |
---|---|
Owner: | changed from peter to nobody |
Summary: | grains convergence problem on second iteration → ionization convergence problem on second iteration |
I can confirm the initial analysis, but the grains are actually a red herring. If you remove the grains completely from the model, you will still see the same pathological behavior. The underlying problem is that the ionization of the first zone on the second iteration does not converge. You typically get a message like:
PROBLEM ConvFail? 1, ionization not converged iteration 2 zone 1 fnzone 37.60
The extreme value for fnzone tells it all... If you compare a model (modified from the attached version) with stop zone 1, 1 or 2 iterations, and no grains, you will see that the number of calls to ConvBase? goes up from 74 in the 1 iteration case to 11056 in the 2 iteration case. This is the true cause of the problem. The grains just get taken along for the ride.
It is true that the grains soak up a lot of CPU time and I will look into optimizing the yield functions, but I am not overly optimistic there. These are extremely simple routines, and there is not much that can be changed there...
Changing "grain convergence" -> "ionization convergence" in summary and component.
Changed 9 years ago by
comment:5 Changed 9 years ago by
Description: | modified (diff) |
---|
comment:6 Changed 8 years ago by
Milestone: | C08.01 → C10 branch |
---|
comment:7 Changed 8 years ago by
More immediate problem on trunk r3469. Parser skips first 3 characters of radius in second and all following lines of density table law. FFmtRead needs to be reset somehow.
comment:8 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Works fine with r6328. Finishes in about 10 seconds with no problems.
Fix formatting of profile output.