[mesa-users] release 4442 -- a few fixes, a new parallel matrix solver, and a request for help

[Bill Paxton]

1) at Max Katz's suggestion, rather than change the default value of mesh_delta_coeff from 1.0, 
I've instead changed the default weights for the default mesh functions to get the same effect.

2) the energy generation from CNO was correct in the models, 
but it was being under-reported in logs for histories and profiles because of a
miscategorization of several reactions that should have been counted as part of CNO but weren't.
with this fixed, you'll see larger values reported for things like L_H.

3) I found and fixed a bug that would have introduced small unwanted variations in metals
mass fractions for accreted material.

4) up to now, we've been using the "divide-and-conquer" algorithm for parallel matrix solves.
this is a great algorithm -- except the results slightly depend on the number of threads.  
starting with this release, we're switching to an even better matrix solver that gives
exactly identical results independent of number of threads.   here are details if you'd
like to learn more about it:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CYCLIC_REDUCTION
Type: application/octet-stream
Size: 3410 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20120830/1c12361a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Hirshman_10_BCYCLIC.pdf
Type: application/pdf
Size: 889883 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20120830/1c12361a/attachment.pdf>
-------------- next part --------------


the new default in controls.defaults selects this new solver so you don't need to change anything to start using it.
small_mtx_decsol = 'bcyclic_dble'

I'm still working on the version of bcyclic to use KLU for sparse blocks; for now it only supports dense blocks.



REQUEST FOR HELP CHECKING FOR BUGS THAT SHOW UP WITH MULTI-THREADING

with the change to bcyclic for matrix solves, there shouldn't be any source of run-to-run variation in mesa.  none.

in other words, if you do ./rn or ./re from exactly the same starting data with the same compiled code
on the same computer, you should get exactly the same results even if you run with a different number of threads.   

so please try it and let me know if you turn up a counter example.  if you find a case where the results 
change from one run to the next without changes to data, code, or machine, and with or without a change in
number of threads, PLEASE LET ME KNOW ABOUT IT since it indicates a bug, and we don't like bugs.  ;-)


Cheers,
Bill