Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macro atoms - one free free errors (2) #511

Closed
kslong opened this issue May 5, 2019 · 4 comments
Closed

macro atoms - one free free errors (2) #511

kslong opened this issue May 5, 2019 · 4 comments

Comments

@kslong
Copy link
Collaborator

kslong commented May 5, 2019

The following macro atom run crashes (on dev) at the beginning of creating a detailed spectrum. This may be related to #492, but the specific error is different and so I am starting a new issue for this problem.

hot.pf.txt

Although the error is a problem with cdf generation, the problem comes from one_free_free as indicated by this traceback:

#0  cdf_gen_from_array (cdf=0x120214a18 <cdf_ff>, x=0x1027beb50 <ff_x>, y=0x1027c0a90 <ff_y>, n_xy=1000, xmin=0, xmax=0) at cdf.c:438
#1  0x000000010003dc53 in one_ff (one=0x13dd94490, f1=0, f2=0) at emission.c:742
#2  0x000000010004d024 in kpkt (p=0x7ffeefbfe7f8, nres=0x7ffeefbfe7e4, escape=0x7ffeefbfe754, mode=1) at matom.c:1183
#3  0x000000010006da80 in macro_gov (p=0x7ffeefbfe7f8, nres=0x7ffeefbfe7e4, matom_or_kpkt=2, which_out=0x7ffeefbfe7e0) at macro_gov.c:164
#4  0x000000010006c2fc in get_matom_f (mode=0) at photo_gen_matom.c:341
#5  0x00000001000106ad in xdefine_phot (f1=599585000000000, f2=3526970588235294, ioniz_or_final=1, iwind=-1, print_mode=1) at photon_gen.c:398
#6  0x000000010000ff8f in define_phot (p=0x14a800000, f1=599585000000000, f2=3526970588235294, nphot_tot=10000000, ioniz_or_final=1, iwind=-1, 
    freq_sampling=0) at photon_gen.c:113
#7  0x000000010007e037 in make_spectra (restart_stat=1) at run.c:565
#8  0x0000000100001c71 in main (argc=3, argv=0x7ffeefbff210) at python.c:915

The problem is related to the fact taht both f1 and f2 are 0 here. The problem occurs when hot.pf is run from scratch and when it is restarted from the end of the ionization cycles (so it is not that something is being overwritten on restart).

@kslong
Copy link
Collaborator Author

kslong commented May 5, 2019

The problem is occurring in these lines of matom.c

  else
  {
    /* in spectral cycles, use the frequency range of the final spectrum */
    freqmin = em_rnge.fmin;
    freqmax = em_rnge.fmax;
  }

For some reason em_rnge.fmin and em_rnge.fmax are both 0.

These are set in setup.c (375 and 376). Further analysis indicates that these lines are not accessed on restarts, so this clearly needs fixing.


I fixed that problem on what is now the bug511_ff branch, and the routine did not fail as quickly, but ulitmately it failed with the same error in one_continuum near line 192 of continuum.c

    if (f_local[nwave - 2] == 0.0)      //We have a zero just inside the end
    {
      nwave++;
      w_local[nwave - 1] = w_local[nwave - 2];
      f_local[nwave - 1] = f_local[nwave - 2];
      w_local[nwave - 2] = w_local[nwave - 3] / (1. - DELTA_V / (2. * C));
      linterp (w_local[nwave - 2], comp[spectype].xmod.w, comp[spectype].xmod.f, comp[spectype].nwaves, &y, 0);
      f_local[nwave - 2] = y;
    }

    /* we should now have our arrays w_local and f_local which can be used to generate a cdf */

    /*  Get_model returns wavelengths in Ang and flux in ergs/cm**2/Ang */

    if (cdf_gen_from_array (&comp[spectype].xcdf, w_local, f_local, nwave, lambdamin, lambdamax) != 0)
    {
      Error ("One_continuum: after return from cdf_gen_from_array\n");
    }
    old_freqmin = freqmin;
    old_freqmax = freqmax;
  }

It appears that this fails, by going through line 147 and then 148 of continuum.c the very first time it passes through this. gdb on my mac does not give quite enough information on what is exactly wrong here.


Note that this part of the error may be associated with the specific model files I used, when I switched to the Kurucz models, the routine ran to completion. It may be relevant that these models cover a larger wavelength range.

@kslong
Copy link
Collaborator Author

kslong commented May 6, 2019

The set of models I have been using is tlusty_d14.ls. This has 681 models, and each model has 27801 bins, but this is less than the maxium 1000 models and 28000 bins. We also check that a model does not have more than NWAVES bins, so it is not obvious why there are errors with this grid, but not the Kurucz model grid.

The problem is that when the program gets to cdf_gen_from array the last two bins in the spectrum have wavelength 5000.0 A. This is the upper limit to the wavelength range. It's as if somehow an additional bin got added. This problem, at this point, is not a macro atom problem, as I have run the same model with standard79 and simple thermal trapping.

@kslong
Copy link
Collaborator Author

kslong commented May 6, 2019

The problem is this code in continuum.c

    /* now check if upper bound is beyond lambdamax, and if so, interpolate to get appropriate flux
       at lambda max. copy to w_local and f_local */
    if (comp[spectype].xmod.w[0] < lambdamax && lambdamax < comp[spectype].xmod.w[comp[spectype].nwaves - 1])
    {
      w_local[nwave] = lambdamax;
      linterp (lambdamax, comp[spectype].xmod.w, comp[spectype].xmod.f, comp[spectype].nwaves, &y, 0);
      f_local[nwave] = y;
      nwave++;
    }

At this point, we already have a point for 5000 A, and this adds another 1.

kslong added a commit that referenced this issue May 6, 2019
…eated for

cdf_gen_from_array does not have two points at the end of the array with the same
wavelength.  See #511.
@kslong kslong mentioned this issue May 6, 2019
kslong added a commit that referenced this issue May 6, 2019
* Removed emrng structure, which was causing problems in restarts of macro-atom models 

* Modifications to one_continuum to assure that  the wavelength array created for
cdf_gen_from_array does not have two points at the end of the array with the same
wavelength.  See #511.
@kslong
Copy link
Collaborator Author

kslong commented May 6, 2019

OK, so this issue is resolved.

Summary: There were two problems both of which generated the same cdf_gen_from_array error:

  • On restarts, the structure em_rng was not being initialized. This was resolved by eliminating the structure and storing the relevant information in geo.
  • In one_continuum, there when the end of the wavelength range for creating a detailed spectrum was the same as a wavelength in a model spectrum, the array being created for cdf_gen_from_array had two wavelengths that were identical. Today's version of cdf_gen_from_array cannot handle this. The solution (changing a <= to < in one of the loops) prevents this from happening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant