Are these errors serious issues ?

[Mohammad Safarzadeh]

I am running SUNRISE on ENZO outputs,

these are a few lines that I see in the ouput log, I wonder if anyone gets the same errors and if they are important ones,

first there is this line in sfrhist stage:

Task 0 created 38508 leaf cells, should be 38508

Allocating a memory block for 38508 cell data objects, 6.75723 MB.

and when I look at the yt exporter for Enzo, I see this :

refinement tree # of cells 591601, # of leaves 517651

but in the yt exported file, dd['HI_density'] has length of 152531  .... ( so I guess this mean the total number of cells that I have in the region that I cut from simulation snapshot) 

so these 3 numbers are different.... Is sunrise refining itself?

second there are thousands of these lines:

PDR radius data not available, can't compute statistics

Asking for SED with S, pressure, Z, age: (5.6271,6.56774,0.0154959,140870,4.78256e-321)

 Returning SED element: (3,3,3,0,1610612736)

PDR radius data not available, can't compute statistics

Asking for SED with S, pressure, Z, age: (5.71398,6.78494,0.0197024,124230,4.78256e-321)

 Returning SED element: (3,3,3,0,-2147483648)

PDR radius data not available, can't compute statistics

Asking for SED with S, pressure, Z, age: (5.72343,6.80856,0.019998,104518,4.78256e-321)

 Returning SED element: (3,3,3,0,536870912)

PDR radius data not available, can't compute statistics

Asking for SED with S, pressure, Z, age: (5.72903,6.82257,0.0201331,76357.9,4.78256e-321)

 Returning SED element: (3,3,3,0,-536870912)

PDR radius data not available, can't compute statistics

Asking for SED with S, pressure, Z, age: (5.72668,6.8167,0.0200461,4421.87,4.78256e-321)

 Returning SED element: (3,3,3,0,-1610612736)

then there are these warnings:

WARNING: 1616 particles outside the metallicity range of the Groves templates (1616 > max, 0 < min). If this number is large it is a problem.

WARNING: 1268 particles outside the compactness parameter range of the Groves templates (1268 > max, 0 < min). If this number is large it is a problem.

WARNING: 2062 particles outside the pressure range of the Groves templates (2057 > max, 5 < min). If this number is large it is a problem.

Calculating SEDs for SB99 particles

WARNING: 40414 particles outside the metallicity range of the SB99 templates (39861 > max, 553 < min). If this number is large it is a problem.

Calculating bolometric luminosities

and then:

Writing output file

  /home/safarzadeh/Sbc-example/Enzo_currected.fits

Warning: No SED defined for species 2, assuming zero

      chunk size is 28 rows

Warning: No SED defined for species 3, assuming zero

      chunk size is 28 rows

      chunk size is 28 rows

Warning: No SED defined for species 5, assuming zero

      chunk size is 28 rows

      chunk size is 28 rows

Warning: No SED defined for species 5, assuming zero

      chunk size is 28 rows

Writing integrated grid SED to HDU INTEGRATED_QUANTITIES

Sfrhist complete

Then it goes to MCRX stage....

Best

Mohammad

[Chris Hayward]

Hi Mohammad,

I don't use yt/Enzo, so someone familiar with that (e.g., Chris Moody) can answer better than I can. However, in general, Sunrise performs refinement on its own (read up on the wiki for details). The refinement criteria important for the radiative transfer (for example, the density gradient) are not, in general, the same that are important for the hydro, so Sunrise does its own refinement.

You don't need to worry about the lines that say "Asking for SED..." However, the statements labeled "WARNING" are definitely important (as you may have guessed). These indicate that your young star particles have properties, such as metallicity, outsider the range of the Groves et al. templates, and you have the same problem for the star particles and the Starburst99 templates. This is strange. Can you please attach your entire sfrhist output?

The remainder of the output looks okay.

Cheers,

Chris

--
You received this message because you are subscribed to the Google Groups "Sunrise" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sunrisemcrx...@googlegroups.com.
To post to this group, send email to sunri...@googlegroups.com.
Visit this group at http://groups.google.com/group/sunrisemcrx?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Chris Hayward
Heidelberger Institut für Theoretische Studien
Schloss-Wolfsbrunnenweg 35
69118 Heidelberg, Germany
Google Voice: +1 (617) 744-9416
Office: +49 6221 533 284
Fax: +49 6221 533 298
http://www.cfa.harvard.edu/~chayward

[mohammad safarzadeh]

here I attach it:

[Chris Hayward]

Hi Mohammad,

Judging from your output, Sunrise is not performing further refinement. So, I don't know why the number of cells is different and must defer to someone familiar with the yt/Enzo functionality.

As I explained, the warnings are because, for example, your particles have metallicities higher than expected. The Groves et al. and SB99 templates extend to 2 Z_sun. I have to check the file to see what is assumed for Z_sun, but I think it is Z_sun = 0.012. Thus, the warning would indicate that you have a significant number of star particles with Z > 0.024. Can you please check whether this is the case? Also, how many particles w/ age < 10 Myr are in this snapshot? How many other star particles?

It is possible that your simulation (and some real galaxies) have regions with, e.g., ISM pressure beyond the range for which the Groves et al. models are calculated. Indeed, this is the reason that I do not use the Groves et al. templates in my submillimeter galaxy work. However, it is important to understand whether this is actually going on and whether it is reasonable. The same goes for the compactness parameter. The metallicity warnings, however, are a bit strange, because I wouldn't expect that you would have that many particles with metallicity >2 Z_sun.

Cheers,

Chris

[mohammad safarzadeh]

I dont know how to get the info about the particles in the simulation snapshot from yt output, but for the cells:

n [9]:z= dd['Metallicity']
yt : [INFO     ] 2013-02-09 17:21:11,272 Getting field Metal_Density from 212
yt : [INFO     ] 2013-02-09 17:21:23,757 Getting field Density from 212
Out[9]: 
array([ 0.53751028,  0.52364069,  0.50216442, ...,  0.1259701 ,
       0.12584902,  0.12572666], dtype=float32)

In [11]: len(z), z.max(), z.min()
Out[11]: 152531, 5.5924482, 0.00022

In [14]: print index=(z>2).nonzero()[0]
Out[14]: 14673

So 14673/152531 is the fraction of cells with z>2. 

I wonder now that SUNRISE is not using the template for the particles with those metallicities, what does it do? ignore them?

+ it takes about 17 hours, to run MCRX on this snapshot on 24 cores.  with ir_tol = 0.9

ir_tol = 0.1 did not finish even after 160 hours....

[Chris Hayward]

Again, I am not familiar with yt/Enzo, but metallicity of 5.59 looks very strange... This is unphysical if it is defined in the usual manner (Z = mass in metals/total mass), and it is still very high if it is in solar units.

Regardless, for the warnings you see, the particle metallicities are what matter. The SED templates are assigned to star particles, and the warnings are printed if the star particles have metallicities less than or greater than the range covered by the templates. If the metallicity is very high, the particles are still included, but they are assigned the highest-metallicity template. So, Sunrise will still run, but your results could be complete nonsense. Thus, it is important to understand the input (and make sure it is sensible) before worrying about the Sunrise run.

Without knowing about your simulation or other parameter settings, I cannot really comment on the time needed, but that does seem too long.

Cheers,

Chris

[mohammad safarzadeh]

I am wondering as the number of star_particles are:

In [20]: len(star_particles)

Out[20]: 1053994

and according to SUNRISE, 

WARNING: 1616 particles outside the metallicity range of the Groves templates (1616 > max, 0 < min). If this number is large it is a problem.

that is very small fraction of the total number of particles, and higher metallicities than 2 I think wont affect the resulting SED as those are quite dead particles and if any they contribute to about 0.1% of the total of stellar particles....

and according to:

WARNING: 40414 particles outside the metallicity range of the SB99 templates (39861 > max, 553 < min). If this number is large it is a problem.

then about 1 % of the particles are problematic. and again I think these might not be a significant problem.

A rough estimate that I did, showed that about 0.1% of the cells are optically thick ( tau > 1) out of 150,000 cells. Do you think these could be the reason why with ir_tol = 0.9 it takes such a long time to finish the job?

Best,

[Chris Hayward]

that is very small fraction of the total number of particles, and higher metallicities than 2 I think wont affect the resulting SED as those are quite dead particles and if any they contribute to about 0.1% of the total of stellar particles....

Yes, it is true that these particles will contribute a relatively small fraction of the total luminosity. However, they are not 'dead'. They are actually very bright because they are very young.

 

The thing to worry about is whether such particles are expected or whether they are indicative of some problem with the simulation. As I said previously, 'metallicity' values of 5.59 would have me worried (if these are indeed the metal fraction). In my opinion, the most important principle in numerical astrophysics is GIGO (http://en.wikipedia.org/wiki/Garbage_in,_garbage_out).

A rough estimate that I did, showed that about 0.1% of the cells are optically thick ( tau > 1) out of 150,000 cells. Do you think these could be the reason why with ir_tol = 0.9 it takes such a long time to finish the job?

At what wavelength are you calculating the optical depth? In general, very optically thick cells cause the dust temperature calculation to take a long time.

If you send your parameter files and the full mcrx output, I can better analyze the situation.

Cheers,

Chris

[Christopher Moody]

Hi Mohammed, Chris,

I agree with everything that Chris has said. I'm not as familiar with the IR calculation as he is, but I can comment on the yt export procedure. Once the octree is generated by yt Sunrise uses this exact backbone without refinement. For particle data it will construct an octree and hence requires refinement tolerances and the like. 

I'm a bit confused -- the number of values in your dd['HI_density'] is *less* than the number of leaves exported by Sunrise. Normally 'dd' refers to full domain, and so that number I would expect to be larger than the region excised by the exporter. That the number of cells=leaves and octs don't line up is disconcerting; they certainly agree for my runs. I would check that the number of cells the yt exporter says it's exporting matches the FITS file by looking that the total number of 0s (leaves) and 1s (refined octs) in the GRIDSTRUCTURE HDU. You can use the GUI FITS viewer "fv" or you can tally it up using python and pyfits. Finally, make sure that this is the number Sunrise also sees. I believe Sunrise checks to make sure that it has read in the full structure, so the fact that sfrhist finishes without error is a pretty good consistency check that the structure is indeed a well behaved Hilbert-ordered octree. 

I think you're already doing this, but if you are not, make sure you are using the dev version of the sunrise exporter -- it's the only version that works with Sunrise v4. 

Good luck,

chris

[mohammad safarzadeh]

The domain that dd[] is being applied is to the cut that I want to extract by YT:

pf = load(EnzoDataName)

fcen = na.array([0.546060026, 0.567523956, 0.537960768])

fwidth = 0.001 #code unit

dd=pf.h.sphere(fcen,fwidth)

Did I understand your comment?

0    PRIMARY     PrimaryHDU       5   ()           uint8   

1    GRIDSTRUCTURE  BinTableHDU     25   591601R x 1C   [B]   

2    GRIDDATA    BinTableHDU     38   517651R x 9C   [D, D, D, D, D, D, D, D, D]   

3    YT          BinTableHDU     13   1R x 1C      [D]   

4    PARTICLEDATA  BinTableHDU     37   1336978R x 10C   [J, J, 3D, 3D, D, D, D, D, D, D]  

for the GRIDSTRUCTURE:

NAXIS2  =               591601 / length of dimension 2    

I get 

Out[8]: FITS_rec([(1), (1), (1), ..., (0), (0), (0)], 

      dtype=[('structure', '|u1')])

I dont know how to get the number of 1s here by pyfits....

[John Wise]

Hi,

I can answer the Enzo/yt question, but I'm only a Sunrise novice. The field "Metal_Density" is the mass density of the metals, not the metallicity. If the export the Sunrise requires metallicity (M/M_Z), then the correct field is "Metal_Fraction". If you ever need it in solar units, then the field is "Metallicity".

John

John Wise
Assistant Professor of Physics
Center for Relativistic Astrophysics, Georgia Tech