Hi there

sorry for the delay - it took a bit of thought to parse the question, and I am
still not sure that I understand it.

>
> I'm trying to figure out an easy way to calculate with Cloudy the emission
measure of my observed lines.

emission measure, usually given as something like n^2 V or n^2 L, can be related
to the luminosity or intensity of a line if there is a single excitation
process.  In the case discussed in AGN3, H recombination lines in nebulae, the H
I  lines form by radiative recombination so the luminosity in the line can be
converted into n^2 V by multiplying by a physical constant that is determined by
the kinetic temperature.

In x-ray lines there will generally be several processes that come in, and the
dominant process for exciting a line may depend on position in the cloud.  This
was the case for the He-like ions discussed in 2007ApJ...664..586P - continuum
pumping, recombination, and collisional processes are each important in
different places.  In such a situation there is no simple relationship between
emission measure and line emission.

one way to think about this would be to look at the output given with the *punch
line emissivity* command, which gives the line emission per unit vol (erg cm-3
s-1) at each point.  The ratio of this emissivity to the product n_2 n_ion would
be a constant if the line formation processes were simple constants.  That will
not happen in any realistic cloud.

rather than converting predictions into something with uncertain meaning, why
not use the emissivity integrated over the cloud?

>
> In principle, I have almost all I need from a Cloudy calculation: the chemical
abundance, the ionic fraction and the radiative recombination coefficient. The
latter is produced by "punch recombination coefficients", and I can select the
one for the relevant ion. However, I still need to 'weight' this emission
measure with the fraction of recombinations which actually leads to the
transition I'm interested to.

and you need to consider collisional excitation and continuum pumping.

>
> For example, take the forbidden line of the OVII Kalpha triplet. I can get the
total recombination coefficient for OVII from the output of "punch
recombination" (although it is not clear to me the difference between the value
listed after 'He-like O   8', and the one listed for each zone and for each ion:
the two are similar, but different). Then I could use the normal output to
weight the forbidden line with respect to the other intense lines from OVII in
that run. But I have no direct information on the radiative recombination
continuum. I think it should be counted. Is there any other way to have the
correction to the recombination coefficient for a particular transition?

this is stored as radiative rates within the model of the ion.  you would need
to get into the code.  However, line optical depths change across the cloud so
these numbers will depend on position within the cloud since the branching
ratios do

>
> Apart from the calculation of the emission measure, the direct estimate of the
flux of RRCs would be interesting. I couldn't find any means to do that in
Cloudy, unless I produce a synthetic spectrum and evaluate the flux from it. Is
there a way to extract the flux of RRCs directly from the calculations, as for
the emission lines?

this is directly predicted and reported.  why not use that??

good luck,
Gary

This is the first one I've gotten in a long time.  It's for a calculation using
unusual abundances -- O-rich ejecta in a SNR.  The odd thing is that using
c07.02.02 it had a floating point exception (which is very weird).  I thought
that I should upgrade to c08 (and hoped that would solve the problem).  The
output is included below.


PROBLEM DISASTER PressureTotal: the chemical species are not conserved.
  The sum of the densities of the atoms and ions for Carbon     is 5.304e+02
which is greater than the gas-phase abundance of the element, 1.245e+02.
  Something that cannot happen, has happened.
  This is TotalInsanity, I live in service.cpp.



            vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
           > PROBLEM DISASTER PROBLEM DISASTER.      <
           > Sorry, something bad has happened.      <
           > Please post this on the Cloudy web site <
           > discussion board at www.nublado.org     <
           > Please send all following information:  <
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


  Cloudy version number is 08.00
  cdInit compiled on Dec 16 2009 in OS Linux (AMD64) using the g++ 40102 compiler
in LP64 mode.

     0 warnings,  0 cautions,  0 temperature failures.  Messages follow.
  Input commands follow:
c ======================
title N132D model using shock emission radiation field
c  Input parameters:
c         ambient density =          4.938
c         ambient B field =          0.222
c     ambient temperature =       1000.000
c          shock velocity =         45.000
c     Rmax =   1.0 Pfac =   1.0 Bfac =   1.0
c  H : 12.00 He: 11.00 C : 14.50 N :  7.99 O : 16.00 Ne: 15.25 Mg: 13.50
c  Si:  7.55 S :  7.21 Ar:  6.58 Ca:  6.36 Fe:  7.67 Ni:  6.25
c  Rmax = 1.0
c  ram pressure relative to Blair et al. = 1.0
c  magnetic field relative to Blair et al. = 1.0
interpolate (0.0000000003 -2.71) (0.000016 6.32) (0.000030 6.53)
continue (0.0000516 6.68) (0.0000897 6.42) (0.000108 6.11) (0.000215 4.49)
continue (0.000553 5.02) (0.00105 5.01) (0.00156 4.72) (0.00383 3.05)
continue (0.0133 3.02) (0.0420 3.56) (0.0729 3.83) (0.130 3.58)
continue (0.259 2.73) (0.365 2.20) (0.412 2.18) (0.448 2.17)
continue (0.449 2.31) (0.484 2.30) (0.486 2.15) (0.521 2.14)
continue (0.523 2.48) (0.558 2.47) (0.559 2.18) (0.595 2.17)
continue (0.596 2.12) (0.631 2.11) (0.633 2.17) (0.668 2.17)
continue (0.670 2.14) (0.705 2.12) (0.706 2.08) (0.742 2.05)
continue (0.743 2.05) (0.778 2.02) (0.780 2.03) (0.815 2.00)
continue (0.817 1.99) (0.852 1.97) (0.853 1.98) (0.889 1.96)
continue (0.890 1.96) (0.925 1.93) (0.927 2.26) (0.962 2.25)
continue (0.9636 1.894) (0.9988 1.873) (1.000 1.021) (1.036 1.021)
continue (1.037 -0.1690) (1.072 -0.1690) (1.074 2.815) (1.109 2.815)
continue (1.111 -0.4799) (1.146 -0.4799) (1.147 1.607) (1.183 1.607)
continue (1.184 -1.337) (1.219 -1.337) (1.221 0.1121) (1.256 0.1121)
continue (1.258 -1.762) (1.293 -1.762) (1.294 2.545) (1.330 2.545)
continue (1.331 -2.123) (1.366 -2.123) (1.368 -2.287) (1.403 -2.287)
continue (1.405 -2.440) (1.440 -2.440) (1.441 -0.1880) (1.477 -0.1880)
continue (1.478 1.800) (1.513 1.800) (1.515 0.1653) (1.550 0.1653)
continue (1.552 0.08801) (1.587 0.08801) (1.588 -0.7566) (1.624 -0.7566)
continue (1.625 1.523) (1.660 1.523) (1.662 1.938) (1.697 1.938)
continue (1.699 -1.886) (1.734 -1.886) (1.735 -2.179) (1.771 -2.179)
continue (1.772 2.182) (1.807 2.182) (1.809 -0.6462) (1.844 -0.6462)
continue (1.846 1.693) (1.881 1.693) (1.882 0.2838) (1.918 0.2838)
continue (1.919 -1.506) (1.954 -1.506) (1.956 1.082) (1.991 1.082)
continue (1.993 1.813) (2.028 1.813) (2.029 -0.3845) (2.065 -0.3845)
continue (2.066 -2.289) (2.101 -2.289) (2.103 2.182) (2.138 2.182)
continue (2.140 -1.013) (2.175 -1.013) (2.176 -2.753) (2.212 -2.753)
continue (2.213 -2.885) (2.248 -2.885) (2.250 -3.005) (2.285 -3.005)
continue (2.287 -3.115) (2.322 -3.115) (2.323 -3.213) (2.359 -3.213)
continue (2.360 1.039) (2.395 1.039) (2.397 -3.382) (2.432 -3.382)
continue (2.434 1.235) (2.469 1.235) (2.470 -3.516) (2.506 -3.516)
continue (2.507 -2.634) (2.542 -2.634) (2.544 0.8858) (2.579 0.8858)
continue (2.581 1.277) (2.616 1.277) (2.617 0.5456) (2.653 0.5456)
continue (2.654 0.3460) (2.689 0.3460) (2.691 0.1518) (2.726 0.1518)
continue (2.728 -0.03656) (2.763 -0.03656) (2.764 -0.2187) (2.800 -0.2187)
continue (2.801 -0.3866) (2.836 -0.3866) (2.838 -0.5631) (2.873 -0.5631)
continue (2.875 0.9927) (2.910 0.9927) (2.912 1.386) (2.983 1.386)
continue (2.986 -0.2566) (3.056 -0.2566) (3.059 -0.7920) (3.130 -0.7920)
continue (3.133 -1.079) (3.203 -1.079) (3.206 -0.3460) (3.277 -0.3460)
continue (3.280 0.2876) (3.350 0.2876) (3.353 -1.843) (3.424 -1.843)
continue (3.427 -2.034) (3.497 -2.034) (3.500 -2.152) (3.571 -2.152)
continue (3.574 0.09524) (3.644 0.09524) (3.647 -1.262) (3.718 -1.262)
continue (3.721 -2.145) (3.791 -2.145) (3.794 -0.1272) (3.865 -0.1272)
continue (3.867 -0.3714) (3.938 -0.3714) (3.941 -0.4578) (4.012 -0.4578)
continue (4.014 1.630) (4.085 1.630) (4.088 -0.9091) (4.159 -0.9091)
continue (4.161 -1.178) (4.232 -1.178) (4.235 -1.453) (4.306 -1.453)
continue (4.308 -1.041) (4.379 -1.041) (4.383 -1.980) (4.489 -1.980)
continue (4.493 -2.283) (4.599 -2.283) (4.603 -0.5859) (4.709 -0.5859)
continue (4.713 -2.084) (4.819 -2.084) (4.824 -1.640) (4.930 -1.640)
continue (4.934 -1.789) (5.040 -1.789) (5.044 -1.429) (5.150 -1.429)
continue (5.154 -3.028) (5.260 -3.028) (5.265 -2.981) (5.371 -2.981)
continue (5.375 -3.265) (5.481 -3.265) (5.485 -2.125) (5.591 -2.125)
continue (5.595 -3.410) (5.701 -3.410) (5.706 -2.045) (5.812 -2.045)
continue (5.817 -2.832) (5.958 -2.832) (5.964 -3.432) (6.105 -3.432)
continue (6.111 -3.422) (6.252 -3.422) (6.258 -3.616) (6.399 -3.616)
continue (6.405 -3.745) (6.546 -3.745) (6.552 -3.810) (6.693 -3.810)
continue (6.699 -3.582) (6.840 -3.582) (6.846 -3.919) (6.987 -3.919)
continue (6.993 -3.972) (7.134 -3.972) (7.140 -3.280) (7.281 -3.280)
continue (7.287 -4.030) (7.464 -4.030) (7.471 -4.105) (7.648 -4.100)
continue (7.655 -4.145) (7.831 -4.140) (7.839 -4.218) (8.015 -4.213)
continue (8.022 -4.221) (8.199 -4.216) (8.206 -4.314) (8.383 -4.309)
continue (8.390 -4.359) (8.566 -4.354) (8.574 -4.402) (8.750 -4.397)
continue (8.758 -4.449) (8.970 -4.443) (8.979 -4.498) (9.190 -4.492)
continue (9.199 -4.544) (9.411 -4.538) (9.420 -4.592) (9.631 -4.586)
continue (9.640 -4.637) (9.852 -4.631) (9.861 -4.681) (10.07 -4.675)
continue (10.08 -4.724) (10.29 -4.718) (10.30 -4.770) (10.55 -4.762)
continue (10.56 -4.818) (10.81 -4.810) (10.82 -4.865) (11.06 -4.856)
continue (11.07 -4.910) (11.32 -4.902) (11.33 -4.954) (11.58 -4.946)
continue (11.59 -4.997) (11.84 -4.989) (11.85 -5.043) (12.13 -5.033)
continue (12.14 -5.089) (12.42 -5.079) (12.43 -5.135) (12.72 -5.125)
continue (12.73 -5.179) (13.01 -5.169) (13.02 -5.222) (13.30 -5.212)
continue (13.32 -5.267) (13.63 -5.256) (13.65 -5.313) (13.97 -5.301)
continue (13.98 -5.358) (14.30 -5.346) (14.31 -5.401) (14.63 -5.389)
continue (14.64 -5.446) (14.99 -5.432) (15.01 -5.491) (15.36 -5.477)
continue (15.38 -5.535) (15.73 -5.521) (15.74 -5.577) (16.10 -5.563)
continue (16.11 -5.621) (16.50 -5.605) (16.52 -5.664) (16.90 -5.648)
continue (16.92 -5.706) (17.31 -5.690) (17.32 -5.746) (17.71 -5.730)
continue (17.73 -5.788) (18.15 -5.769) (18.17 -5.829) (18.59 -5.810)
continue (18.61 -5.868) (19.03 -5.849) (19.05 -5.908) (19.51 -5.887)
continue (19.53 -5.947) (19.99 -5.926) (20.01 -5.984) (20.47 -5.962)
continue (20.49 -6.022) (20.98 -5.998) (21.00 -6.058) (21.50 -6.034)
continue (21.52 -6.090) (22.01 -6.066) (22.03 -6.127) (22.56 -6.101)
continue (22.58 -6.160) (23.11 -6.134) (23.13 -6.192) (23.66 -6.165)
continue (23.69 -6.223) (24.25 -6.194) (24.27 -6.253) (24.84 -6.223)
continue (24.86 -6.282) (25.46 -6.250) (25.49 -6.309) (26.09 -6.276)
continue (26.11 -6.334) (26.71 -6.300) (26.74 -6.358) (27.37 -6.322)
continue (27.40 -6.380) (28.03 -6.344) (28.06 -6.402) (28.73 -6.363)
continue (28.76 -6.421) (29.43 -6.381) (29.46 -6.439) (30.16 -6.396)
continue (30.19 -6.454) (30.90 -6.411) (30.93 -6.468) (31.67 -6.422)
continue (31.70 -6.479) (32.44 -6.432) (32.47 -6.489) (33.25 -6.439)
continue (33.28 -6.495) (34.06 -6.444) (34.09 -6.500) (34.90 -6.446)
continue (34.94 -6.502) (35.78 -6.445) (35.82 -6.501) (36.67 -6.443)
continue (36.70 -6.498) (37.58 -6.435) (37.62 -6.489) (38.50 -6.421)
continue (38.54 -6.474) (39.46 -6.402) (39.50 -6.455) (40.45 -6.380)
continue (40.49 -6.431) (41.44 -6.354) (41.48 -6.405) (42.47 -6.323)
continue (42.51 -6.374) (43.53 -6.288) (43.58 -6.337) (44.64 -6.247)
continue (44.68 -6.295) (45.74 -6.203) (45.78 -6.249) (46.88 -6.152)
continue (46.92 -6.198) (48.05 -6.095) (48.10 -6.140) (49.26 -6.032)
continue (49.31 -6.075) (50.48 -5.965) (50.53 -6.006) (51.73 -5.891)
continue (51.78 -5.930) (53.01 -5.809) (53.06 -5.847) (54.33 -5.720)
continue (54.39 -5.755) (55.69 -5.622) (55.75 -5.656) (57.09 -5.516)
continue (57.14 -5.547) (58.52 -5.402) (58.58 -5.430) (59.99 -5.278)
continue (60.05 -5.303) (61.50 -5.144) (61.56 -5.166) (63.04 -4.999)
continue (63.10 -5.018) (64.62 -4.845) (64.68 -4.860) (66.23 -4.678)
continue (66.30 -4.690) (67.89 -4.501) (67.95 -4.508) (69.58 -4.310)
continue (69.65 -4.313) (71.30 -4.108) (71.37 -4.106) (73.10 -3.887)
continue (73.2 -3.88) (73.9 -3.79) (304. -4.30) (30400000 -14.3)
f(nu) = -25.71 at 16.92 Ryd
cosmic rays background
hden 0.3937 linear
abundances He -1.00  Li -8.69  Be -10.58  B -9.12  C 2.50  N -4.01  O 4.00
continue F -20.00  Ne 3.25  Na -5.69  Mg 1.50  Al -7.10  Si -4.45
continue P -6.66  S -4.79  Cl -6.73  Ar -5.42  K -7.96  Ca -5.64
continue Sc -20.00  Ti -8.38  V -10.00  Cr -7.39  Mn -7.37  Fe -4.33
continue Co -8.63  Ni -5.75  Cu -8.55  Zn -7.38
grains
constant density
stop zone 20
stop temperature 300
stop column density = 14
punch continuum "shock_emis.con2" units microns last
print last
print every 1
iterate 3 times
c ======================
  [Stop in TotalInsanity at service.cpp:971, something went wrong]

Hi Gary,

More than any problems for c08.00, I wanted to point out that Cloudy is
presently working very fine, and that I'm sure a lot of people is using it. Most
of us call Cloudy through a set of routines and use also some programs to deal
with the outputs. Thus, any changes in the input or output files (format,
keywords) will result in a rewritten of these routines. I know that updating to
a new release of a code is always implying some adaptation of the user, but the
backward compatibility of all the user-side files is also very important to
allow a quick and painless transition.

Could it thus be possible to:
1) limit at maximum the changes in the keywords. For example, what is the need
of changing "punch" to "save", or "assert" to "monitor"? It will basically imply
that we will have to check and change all our input files. Seems that "Punch" is
still understood, thus we will have in a few years people dealing with the new
way and others with the oldish way. I'm not sure it helps the inter-generation
communication ;-)
In the second example: "assert" is now totally banned from the input files... No
way to use the oldish semantic.
2) limit at maximum the changes in the output formats. I remember a new header
line introduced in some output file when c08.00 arrived, causing the routines
reading the outputs to crash. Or the change of SPACE- to TAB-separated output
tables...
3) limit the changes in the user-defined functions, e.g. dense_fabden.cpp, which
seems to have changed in such a way that old versions are not accepted...
4) document carefully and completely all the remaining changes, so that it will
help us to adapt the routines (and ourself ;-) ) to these changes.

Thanks a lot for all your efforts in providing this new version, best regards,
Christophe


--- In cloudy_simulations@yahoogroups.com, "Gary Ferland" <gjferland@...> wrote:
>
> Greetings,
>
> It is our intention to release a new version of Cloudy every two years.  We
are approaching the 2-year anniversary of C08 and are making plans for the C10
release.
>
> Now would be a good time to let us know of any serious problems with C08 that
have not been posted on this group.  If you have a problem with a particular
simulation don't forget to post enough information for us to run the sim
ourselves.
>
> good luck,
> Gary
>

Hello,

thank you very much for the clarifications.

> The APERTURE command only affects the spectrum printed in the regular
> output, not the output of the PUNCH CONTINUUM command. This does seem
> inconsistent and I have opened a ticket on this. But a fix for that will
> not be a part of the upcoming release.

I assume the "regular output" is the output that is printed on the screen (or
saved in *.out) when running the code?
Is the command "print continuum block" affected by the aperture command and
could I use that to get a spectrum affected by the aperture?
Or, in other words, is there a quick workaround to get a spectrum that will show
the effects of an aperture?
This is very crucial to what I am trying to find out, therefore any help would
be greatly appreciated.

Thanks a lot,

    Daniela

Hi Linda,

Thanks for the report! We could indeed reproduce the problem with c08.
Since that release there has been a major rewrite of the electron
density and temperature solvers, so I also tried it with the current
development version. That ran fine when I disabled a problematic assert
(we already agreed that this assert will be disabled in the upcoming
release). Since the fix for this problem is an elaborate rewrite of the
solvers, we will not backport it to c08, but this will run fine in the
upcoming c10 release, so you will have to be a bit patient I am afraid...


Thanks again!

Peter.

On 10/12/09 18:51, lindastrubbe wrote:
> Hello there,
>
> I have managed to produce a problem disaster.  The info is below.  Thanks for
your help!
>
> Linda Strubbe
>
>
>
>            vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>            >  PROBLEM DISASTER PROBLEM DISASTER.<
>            >  Sorry, something bad has happened.<
>            >  Please post this on the Cloudy web site<
>            >  discussion board at www.nublado.org<
>            >  Please send all following information:<
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Cloudy version number is 08.00
>   cdInit compiled on Nov  6 2008 in OS Apple MacOS using the g++ 40001
compiler in ILP32 mode.
>
>      0 warnings,  1 cautions,  0 temperature failures.  Messages follow.
>   C-An ionization oscillation occurred at zone 106, elem K  3, by 76% from
1.33e-01 to 5.23e-02 to 9.19e-02
>   Input commands follow:
> c ======================
> age log       5.93651
> print ages
> sphere static
> radius        15.139017       15.342365
> hden 8.7602846
> c
> luminosity total        43.985675
> blackbody       4.2137020
> iterate to convergence
> set punch Lwidth 1500 km/s
> punch lines, array "a.lines" units eV last
> punch overview "a.ovr" last
> punch continuum "a.con" units eV last
> punch line optical depths "a.linetau" last
> punch element heli density "a.Hedens" last
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
--
Peter van Hoof
Royal Observatory of Belgium
Ringlaan 3
1180 Brussel
Belgium
http://homepage.oma.be/pvh

Hello there,

I have managed to produce a problem disaster.  The info is below.  Thanks for
your help!

Linda Strubbe



           vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
           > PROBLEM DISASTER PROBLEM DISASTER.      <
           > Sorry, something bad has happened.      <
           > Please post this on the Cloudy web site <
           > discussion board at www.nublado.org     <
           > Please send all following information:  <
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Cloudy version number is 08.00
  cdInit compiled on Nov  6 2008 in OS Apple MacOS using the g++ 40001 compiler
in ILP32 mode.

     0 warnings,  1 cautions,  0 temperature failures.  Messages follow.
  C-An ionization oscillation occurred at zone 106, elem K  3, by 76% from
1.33e-01 to 5.23e-02 to 9.19e-02
  Input commands follow:
c ======================
age log       5.93651
print ages
sphere static
radius        15.139017       15.342365
hden 8.7602846
c
luminosity total        43.985675
blackbody       4.2137020
iterate to convergence
set punch Lwidth 1500 km/s
punch lines, array "a.lines" units eV last
punch overview "a.ovr" last
punch continuum "a.con" units eV last
punch line optical depths "a.linetau" last
punch element heli density "a.Hedens" last

> I am trying to use Cloudy to study the dissociation rate of H2 due to a
background (blackbody) source. I was wondering if there is a way to use a
blackbody SED but force the shape to go to zero above a certain wavelength.

the extinguish command will remove high-energy radiation.  if you want to remove
low energy light, try the "punch transmitted continuum" / "table read" pair of
commands described in hazy (look up table read) and edit the intermediate file.

>
> Also, as I have been looking through Hazy, I have found a command to write out
a bunch of information about H2 (punch H2 destruction rates), is there another
document to look at to understand all that it is outputting?
>

there are several punch H2 commands that give H2 dissociation rates along with
other information.  the first line of the output is an indication of the
quantity listed.
good luck,
Gary

Hi Peter,
Very weird.  I thought perhaps I should be running cloudy.exe from within the
source subdirectory, so I did -- I ran cloudy.exe <../pn.in >pn.out  and it gave
a different answer that looked right.  In fact, in the previous cases the output
was increasing in wavelength starting from a strange value of 1.05E-8, but the
new .con file started at 8.66E+6 and decreases in wavelength.  It also looks
fine, and has the lines it should. Then I tried again running cloudy.exe from
within the main c08.00 directory, and the new runs agreed with the last
(correct) run.  It is as though a few parameters had to get themselves sorted
out, but now they are working ??! I tried the broad line region and it seems
reasonable too. Maybe I'm all set....

Thanks again for all your help.
Howard



--- In cloudy_simulations@yahoogroups.com, Peter van Hoof <p.vanhoof@...> wrote:
>
> Hi Howard,
>
> > I made a file test.in containing only the line "test".
> > Then I ran  source/cloudy.exe <test.in >test.out
> >
> > Here are the last lines of the test.out file:
> >
> >
> > =============Results of asserts: Cloudy 08.00 Mon Dec  7 16:35:02 2009
> >  No errors were found.  Summary follows.
> >                   Label line    computed     asserted Rel Err Set err
> >  ChkAssert --     HYDR      1    -3.0522 =    -3.0400   0.028   0.050
> >  ChkAssert -      HELI      2    -1.0755 =    -1.0670   0.019   0.050
> >  ChkAssert        CARB      2    -2.3060 =    -2.3010   0.011   0.050
> >  ChkAssert        CARB      3    -0.5599 =    -0.5600  -0.000   0.050
> >  ChkAssert        CARB      4    -0.3732 =    -0.3730   0.000   0.050
> >  ChkAssert        CARB      5    -0.5293 =    -0.5300  -0.002   0.050
> >  ChkAssert        OXYG      3    -0.8613 =    -0.8610   0.001   0.050
> >  ChkAssert        OXYG      4    -0.1569 =    -0.1570  -0.000   0.050
> >  ChkAssert        OXYG      5    -0.8082 =    -0.8080   0.000   0.050
> >  ChkAssert        CA B  4861A     1.1162 =     1.1080  -0.007   0.050
> >  ChkAssert        O  3  5007A     3.1964 =     3.1800  -0.005   0.050
> >  ChkAssert -      heat      0   -15.0176 =   -15.0110   0.015   0.050
> >
> >  cdInit compiled on Dec  7 2009 in OS Linux (AMD64) using the g++ 40102
compiler in LP64 mode.
> >
> >  Cloudy ends:   2 zones,   1 iteration.  ExecTime(s) 2.51
> >  [Stop in main at maincl.cpp:331, Cloudy exited OK]
> > hsmith kochav 154>
> >
> >
> > The rest of the file seemed reasonable.  By the way, to be more detailed
about the nature of the planetary nebula (as-per-the-Manual) test, when I plot
up pn.con I see that at a wavelength of 1.0 microns the continuum drops from
2E-2 down to 9E-4, and then
> > stays around E-5, and at 3.0 microns it starts a rapid series of lines down
to E-25.  When I look ion the file for the NeII line at 12.8um, for example, it
is not present at all.  ?
>
> This looks fine. We would indeed need to see a plot. Maybe something
> went wrong when you extracted the data from the punch file into your
> plotting program? You need to plot the 4th against the 1st column.
>
> Cheers,
>
> Peter.
>
> --
> Peter van Hoof
> Royal Observatory of Belgium
> Ringlaan 3
> 1180 Brussel
> Belgium
> http://homepage.oma.be/pvh
>

Hi Daniela,


> first of all, thanks a lot for the recent help with my problem with
> the incident continuum.
>
> I'd like to report two more problems that I have encountered and ask
> for advice.
>
> 1) I have tried to run scripts using the aperture command. I assumed
> that they would notably change the net transmitted spectrum, but find
> that the output of "punch continuum" with and without the aperture
> command is exactly the same. Is this intended, and did I understand
> the command incorrectly, or is there some other underlying problem?
> Some clarification on the proper usage and what is expected to change
> using the aperture would be greatly appreciated.

The APERTURE command only affects the spectrum printed in the regular
output, not the output of the PUNCH CONTINUUM command. This does seem
inconsistent and I have opened a ticket on this. But a fix for that will
not be a part of the upcoming release.

There is a bug in that the line labels in the PUNCH CONTINUUM output
change when the aperture command is used.

> 2) I started incorporating the ISM abundances into my scripts, and
> find that if I make the distance of the inward face of the cloud to
> the central source small enough, I get an assert thrown and the error
> message following below.The assert occurs e.g. for a radius of 1e-3
> linear parsecs and a density of 1cm^-3, or 1e-5 linear parsecs and a
> density of 1000 cm^-3. I assume the reason for this might be that if
> the cloud starts too close to an ionizing source, they are
> evaporated, and maybe that causes problems?

This is a bug in the code that has now been fixed. The grains were
charged to extremely high potentials, exposing a weakness in the code
calculating the photoelectric yield.

There were indeed warnings about the grains heating to temperatures
above the sublimation temperature, so it is doubtful that grains would
survive very long in such a harsh environment. Also Coulomb explosions
could destroy small grains. But neither of that should cause the code to
crash.

If you change line 3700 of grains.cpp to

if( yh/sqR0 < 0.01 )

the code should run fine.

> The error message below also includes the input script used in both
> cases, in the first case once with and once without the aperture beam
> command uncommented.
>
> Thanks a lot for your help,

Thanks for reporting these problems!

Peter.

--
Peter van Hoof
Royal Observatory of Belgium
Ringlaan 3
1180 Brussel
Belgium
http://homepage.oma.be/pvh

Hi Howard,

> I made a file test.in containing only the line "test".
> Then I ran  source/cloudy.exe <test.in >test.out
>
> Here are the last lines of the test.out file:
>
>
> =============Results of asserts: Cloudy 08.00 Mon Dec  7 16:35:02 2009
>  No errors were found.  Summary follows.
>                   Label line    computed     asserted Rel Err Set err
>  ChkAssert --     HYDR      1    -3.0522 =    -3.0400   0.028   0.050
>  ChkAssert -      HELI      2    -1.0755 =    -1.0670   0.019   0.050
>  ChkAssert        CARB      2    -2.3060 =    -2.3010   0.011   0.050
>  ChkAssert        CARB      3    -0.5599 =    -0.5600  -0.000   0.050
>  ChkAssert        CARB      4    -0.3732 =    -0.3730   0.000   0.050
>  ChkAssert        CARB      5    -0.5293 =    -0.5300  -0.002   0.050
>  ChkAssert        OXYG      3    -0.8613 =    -0.8610   0.001   0.050
>  ChkAssert        OXYG      4    -0.1569 =    -0.1570  -0.000   0.050
>  ChkAssert        OXYG      5    -0.8082 =    -0.8080   0.000   0.050
>  ChkAssert        CA B  4861A     1.1162 =     1.1080  -0.007   0.050
>  ChkAssert        O  3  5007A     3.1964 =     3.1800  -0.005   0.050
>  ChkAssert -      heat      0   -15.0176 =   -15.0110   0.015   0.050
>
>  cdInit compiled on Dec  7 2009 in OS Linux (AMD64) using the g++ 40102
compiler in LP64 mode.
>
>  Cloudy ends:   2 zones,   1 iteration.  ExecTime(s) 2.51
>  [Stop in main at maincl.cpp:331, Cloudy exited OK]
> hsmith kochav 154>
>
>
> The rest of the file seemed reasonable.  By the way, to be more detailed about
the nature of the planetary nebula (as-per-the-Manual) test, when I plot up
pn.con I see that at a wavelength of 1.0 microns the continuum drops from 2E-2
down to 9E-4, and then
> stays around E-5, and at 3.0 microns it starts a rapid series of lines down to
E-25.  When I look ion the file for the NeII line at 12.8um, for example, it is
not present at all.  ?

This looks fine. We would indeed need to see a plot. Maybe something
went wrong when you extracted the data from the punch file into your
plotting program? You need to plot the 4th against the 1st column.

Cheers,

Peter.

--
Peter van Hoof
Royal Observatory of Belgium
Ringlaan 3
1180 Brussel
Belgium
http://homepage.oma.be/pvh

> The rest of the file seemed reasonable.  By the way, to be more detailed about
the nature of the planetary nebula (as-per-the-Manual) test, when I plot up
pn.con I see that at a wavelength of 1.0 microns the continuum drops from 2E-2
down to 9E-4, and then
> stays around E-5, and at 3.0 microns it starts a rapid series of lines down to
E-25.  When I look ion the file for the NeII line at 12.8um, for example, it is
not present at all.  ?
>

how about posting the figure of the spectrum, and the input script?

> The rest of the file seemed reasonable.  By the way, to be more detailed about
the nature of the planetary nebula (as-per-the-Manual) test, when I plot up
pn.con I see that at a wavelength of 1.0 microns the continuum drops from 2E-2
down to 9E-4, and then
> stays around E-5, and at 3.0 microns it starts a rapid series of lines down to
E-25.  When I look ion the file for the NeII line at 12.8um, for example, it is
not present at all.  ?
>

how about posting the figure of the spectrum, and the input script?

Hi Peter,

I made a file test.in containing only the line "test".
Then I ran  source/cloudy.exe <test.in >test.out

Here are the last lines of the test.out file:


=============Results of asserts: Cloudy 08.00 Mon Dec  7 16:35:02 2009
  No errors were found.  Summary follows.
                   Label line    computed     asserted Rel Err Set err
  ChkAssert --     HYDR      1    -3.0522 =    -3.0400   0.028   0.050
  ChkAssert -      HELI      2    -1.0755 =    -1.0670   0.019   0.050
  ChkAssert        CARB      2    -2.3060 =    -2.3010   0.011   0.050
  ChkAssert        CARB      3    -0.5599 =    -0.5600  -0.000   0.050
  ChkAssert        CARB      4    -0.3732 =    -0.3730   0.000   0.050
  ChkAssert        CARB      5    -0.5293 =    -0.5300  -0.002   0.050
  ChkAssert        OXYG      3    -0.8613 =    -0.8610   0.001   0.050
  ChkAssert        OXYG      4    -0.1569 =    -0.1570  -0.000   0.050
  ChkAssert        OXYG      5    -0.8082 =    -0.8080   0.000   0.050
  ChkAssert        CA B  4861A     1.1162 =     1.1080  -0.007   0.050
  ChkAssert        O  3  5007A     3.1964 =     3.1800  -0.005   0.050
  ChkAssert -      heat      0   -15.0176 =   -15.0110   0.015   0.050

  cdInit compiled on Dec  7 2009 in OS Linux (AMD64) using the g++ 40102 compiler
in LP64 mode.

  Cloudy ends:   2 zones,   1 iteration.  ExecTime(s) 2.51
  [Stop in main at maincl.cpp:331, Cloudy exited OK]
hsmith kochav 154>


The rest of the file seemed reasonable.  By the way, to be more detailed about
the nature of the planetary nebula (as-per-the-Manual) test, when I plot up
pn.con I see that at a wavelength of 1.0 microns the continuum drops from 2E-2
down to 9E-4, and then
stays around E-5, and at 3.0 microns it starts a rapid series of lines down to
E-25.  When I look ion the file for the NeII line at 12.8um, for example, it is
not present at all.  ?

Howard



--- In cloudy_simulations@yahoogroups.com, Peter van Hoof <p.vanhoof@...> wrote:
>
> Hi Howard,
>
>
> > Thanks for your quick response.
> >
> > I'm running CentOS 5.4 in a KDE environment from my institution's system
> > managed machine.
> >
> >  > tar --version
> > tar (GNU tar) 1.15.1
>
> OK, so you have a fairly recent Linux distro. You don't have the most
> recent version of tar, but I believe that this version should support
> the z option (it has been supported for many years), so I don't
> understand why it complained. I would need to see the error message.
> Anyway, we got past that problem by manually uncompressing the tar ball,
> so that should be OK.
>
> > So I re-unzipped and tar -xf the whole c.08.00 ball into a new
> > directory. Then I went
> > into source and did the +x permission on the .pl file -- that did seem
> > to make a difference, but I got a lot of what seemed to be compiling
> > errors, and the test pn.com file was wrong, so I did it all again but
> > did +x for *all* of the .pl files in source (but only those). I
> > recompiled again, and still got what looks like errors - here is a sample:
> >
> > hsmith kochav 115> make
> > Updating dependency file, this may take a little while
> > g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g -o
> > cddefines.h.gch cddefines.h
> > g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o maincl.o
> > maincl.cpp
> > g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> > abund_starburst.o abund_starburst.cpp
> > g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> > abundances.o abundances.cpp
> > g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> > age_check.o age_check.cpp
> > g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> > assert_results.o assert_results.cpp
> > g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> > atmdat_2photon.o atmdat_2photon.cpp
> > g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> > atmdat_3body.o atmdat_3body.cpp
> > ....
> > ....  [and the last lines]
> >
> > g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> > zone_startend.o zone_startend.cpp
> > ar ru libcloudy.a abund_starburst.o abundances.o age_check.o
> > assert_results.o atmdat_2photon.o atmdat_3body.o atmdat_HS_caseb.o
> > atmdat_adfa.o atmdat_char_tran.o atmdat_chianti.o atmdat_dielrec_fe.o
> > atmdat_dielsupres.o atmdat_lamda.o atmdat_ligbar.o atmdat_lines_setup.o
> > atmdat_outer_shell.o atmdat_readin.o atom_fe2ovr.o atom_feii.o
> > atom_hyperfine.o atom_level2.o atom_level3.o atom_leveln.o atom_oi.o
> > atom_pop2.o atom_pop3.o atom_pop5.o atom_seq_beryllium.o
> > atom_seq_boron.o cddrive.o cdgetlinelist.o cdinit.o cdspec.o cloudy.o
> > cont_createmesh.o cont_createpointers.o cont_ffun.o cont_gammas.o
> > cont_gaunt.o cont_ipoint.o cont_negative.o cont_pump.o
> > cont_setintensity.o container_classes.o conv_base.o conv_eden_ioniz.o
> > conv_fail.o conv_init_solution.o conv_ioniz.o conv_itercheck.o
> > conv_pres_temp_eden_ioniz.o conv_temp_eden_ioniz.o cool_alum.o
> > cool_argo.o cool_calc.o cool_carb.o cool_chlo.o cool_chro.o cool_coba.o
> > cool_dima.o cool_etc.o cool_eval.o cool_fluo.o cool_iron.o cool_magn.o
> > cool_mang.o cool_neon.o cool_nick.o cool_nitr.o cool_oxyg.o cool_phos.o
> > cool_pota.o cool_pr.o cool_punch.o cool_scan.o cool_sili.o cool_sodi.o
> > cool_sulf.o cool_tita.o cool_vana.o cool_zinc.o cpu.o dense_fabden.o
> > dense_tabden.o dynamics.o eden_sum.o grains.o grains_mie.o
> > grains_qheat.o grid_do.o grid_xspec.o hash.o hcmap.o heat_punch.o
> > heat_sum.o helike_cs.o helike_einsta.o helike_energy.o helike_recom.o
> > highen.o hydro_bauman.o hydro_recom.o hydro_vs_rates.o hydrocollid.o
> > hydroeinsta.o hydrolevel.o hydrooscilstr.o hydroreccool.o hydrot2low.o
> > hypho.o init_coreload.o init_coreload_postparse.o
> > init_defaults_preparse.o init_sim_postparse.o input.o ion_alumi.o
> > ion_argon.o ion_beryl.o ion_boron.o ion_calci.o ion_carbo.o ion_chlor.o
> > ion_chrom.o ion_cobal.o ion_collis.o ion_coppe.o ion_fluor.o
> > ion_helium.o ion_iron.o ion_lithi.o ion_magne.o ion_manga.o ion_neon.o
> > ion_nicke.o ion_nitro.o ion_oxyge.o ion_phosi.o ion_photo.o ion_potas.o
> > ion_recomb.o ion_recomb_Badnell.o ion_scand.o ion_silic.o ion_sodiu.o
> > ion_solver.o ion_sulph.o ion_titan.o ion_trim.o ion_vanad.o ion_zero.o
> > ion_zinc.o iso_collide.o iso_continuum_lower.o iso_cool.o iso_create.o
> > iso_error.o iso_ionize_recombine.o iso_level.o iso_photo.o
> > iso_radiative_recomb.o iso_solve.o iter_end_chk.o iter_startend.o
> > lines_service.o magnetic.o mean.o molcol.o mole_co_atom.o
> > mole_co_drive.o mole_co_etc.o mole_co_reactions.o mole_co_solve.o
> > mole_co_step.o mole_h2.o mole_h2_coll.o mole_h2_create.o mole_h2_etc.o
> > mole_h2_form.o mole_h2_io.o mole_h_drive.o mole_h_step.o nemala.o
> > nemala2.o opacity_add1element.o opacity_add1subshell.o
> > opacity_addtotal.o opacity_createall.o opacity_zero.o optimize_do.o
> > optimize_func.o optimize_phymir.o optimize_subplx.o parse_CMB.o
> > parse_absmag.o parse_abundances.o parse_age.o parse_agn.o
> > parse_atom_co.o parse_atom_h2.o parse_atom_iso.o parse_backgrd.o
> > parse_blackbody.o parse_caseb.o parse_commands.o parse_compile.o
> > parse_constant.o parse_coronal.o parse_cosmic_rays.o parse_crashdo.o
> > parse_dlaw.o parse_dont.o parse_drive.o parse_element.o
> > parse_extinguish.o parse_f_nu.o parse_fluc.o parse_globule.o
> > parse_grain.o parse_grid.o parse_hden.o parse_init.o parse_interp.o
> > parse_ionpar.o parse_map.o parse_metal.o parse_norm.o parse_optimize.o
> > parse_plot.o parse_powerlawcontinuum.o parse_print.o parse_punch.o
> > parse_radius.o parse_rangeoption.o parse_ratio.o parse_set.o
> > parse_sphere.o parse_state.o parse_stop.o parse_table.o parse_test.o
> > parse_tlaw.o parse_trace.o plot.o pressure_change.o pressure_total.o
> > prt.o prt_alltau.o prt_columns.o prt_comment.o prt_continuum.o
> > prt_final.o prt_header.o prt_linepres.o prt_lines.o
> > prt_lines_continuum.o prt_lines_general.o prt_lines_grains.o
> > prt_lines_helium.o prt_lines_hydro.o prt_lines_lv1_k_zn.o
> > prt_lines_lv1_li_ne.o prt_lines_lv1_na_ar.o prt_lines_molecules.o
> > prt_linesum.o prt_meanion.o prt_met.o prt_zone.o punch_average.o
> > punch_colden.o punch_do.o punch_fits.o punch_line.o punch_linedata.o
> > punch_opacity.o punch_special.o radius_first.o radius_increment.o
> > radius_next.o rt_continuum_shield_fcn.o rt_diffuse.o rt_escprob.o
> > rt_line_all.o rt_line_driving.o rt_line_one.o rt_line_one_tau_reset.o
> > rt_line_one_tauinc.o rt_ots.o rt_recom_effic.o rt_stark.o rt_tau_inc.o
> > rt_tau_init.o rt_tau_reset.o sanity_check.o service.o stars.o state.o
> > temp_change.o thirdparty.o thirdparty_interpolate.o thirdparty_lapack.o
> > vary_input.o warnings.o zero.o zone_startend.o
> > ar: creating libcloudy.a
> > ranlib libcloudy.a
> > g++ -O3 -ftrapping-math -fno-math-errno -Wall -g -o cloudy.exe maincl.o
> > -L. -lcloudy
> > hsmith kochav 116>
>
> That looks perfectly OK.
>
> > I cannot tell if these are botched assets or not, but these are all the
> > final lines.
>
> I was asking about the final lines in the file pn.out, but I realize now
> that it is not part of the test suite, so there will be no asserts in
> there. So disregard that question.
>
> Could you run the smoke test by creating an input file with the single
> command
>
> test
>
> and run that. Could you then look if the code reports any problems at
> the end of the output file?
>
>
> Cheers,
>
> Peter.
>
> > --- On *Thu, 12/3/09, Peter van Hoof /<p.vanhoof@...>/* wrote:
> >
> >
> >     From: Peter van Hoof <p.vanhoof@...>
> >     Subject: Re: [cloudy_simulations] brand new user query
> >     To: cloudy_simulations@yahoogroups.com
> >     Date: Thursday, December 3, 2009, 10:53 AM
> >
> >
> >
> >     Hi,
> >
> >      > I have installed CLOUDY for the first time - c.08.00. Since I could
> >      > not locate anyone at CfA running it to ask, I thought I'd post this
> >      > very simple query here.
> >      >
> >      > I'm on a Linux machine running KDE. The "tar -xfz name.tar.gz"
> >      > complained about the z, so I had to unzip it with just -xf. That
> >      > seemed to go fine though. Then I ran "make" - and got the following
> >      > message:
> >
> >     What Linux version is this? And what tar version do you have? Could you
> >     give the output of
> >
> >     tar --version
> >
> >     I suspect that you have a very ancient Linux distribution.
> >
> >      > hsmith kochav 39> make make: execvp: ./precompile. pl: Permission
> >      > denied Updating dependency file, this may take a little while make:
> >      > execvp: ./precompile. pl: Permission denied g++ -ansi -O3
> >      > -ftrapping-math -fno-math-errno -Wall -g -c -o maincl.o maincl.cpp
> >      > g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g -c -o
> >      > abund_starburst. o a bund_starburst. cpp g++ -ansi -O3
> >     -ftrapping-math
> >      > -fno-math-errno -Wall -g -c -o abundances.o abunda nces.cpp etc etc
> >      > etc etc for many lines, ending with:
> >
> >     This sounds like the file ./precompile. pl has the wrong
> >     permissions. Tar
> >     should have done this right... But you can fix this with
> >
> >     chmod +x precompile.pl
> >
> >     in the source directory.
> >
> >      > warnings.o zero.o zone_startend. o ar: creating libcloudy.a ranlib
> >      > libcloudy.a g++ -O3 -ftrapping-math -fno-math-errno -Wall -g -o
> >      > cloudy.exe maincl.o -L. -lcloudy hsmith kochav 40>
> >      >
> >      > But in the end everything looked "normal." I ran the sample:
> >      > cloudy.exe <pn.in >pn.out and got no errors. But when I plot ps.con,
> >      > I do not quite get the nice credible results in Fig 1 of the
> >      > quick-guide start: the continuum plunges down in the visible, and
> >      > other quirks appear. There does not seem to be any Ne emission FS
> >      > lines in the infrared.
> >      >
> >      > Can you help me sort things out a bit? Thanks.
> >
> >     Could you look at the end of the output file and tell us if there are
> >     any reports of botched asserts?
> >
> >     Cheers,
> >
> >     Peter.
> >
> >     --
> >     Peter van Hoof
> >     Royal Observatory of Belgium
> >     Ringlaan 3
> >     1180 Brussel
> >     Belgium
> >     http://homepage. oma.be/pvh <http://homepage.oma.be/pvh>
> >
> >
> >
> >
> >
>
> --
> Peter van Hoof
> Royal Observatory of Belgium
> Ringlaan 3
> 1180 Brussel
> Belgium
> http://homepage.oma.be/pvh
>

Hi Howard,


> Thanks for your quick response.
>
> I'm running CentOS 5.4 in a KDE environment from my institution's system
> managed machine.
>
>  > tar --version
> tar (GNU tar) 1.15.1

OK, so you have a fairly recent Linux distro. You don't have the most
recent version of tar, but I believe that this version should support
the z option (it has been supported for many years), so I don't
understand why it complained. I would need to see the error message.
Anyway, we got past that problem by manually uncompressing the tar ball,
so that should be OK.

> So I re-unzipped and tar -xf the whole c.08.00 ball into a new
> directory. Then I went
> into source and did the +x permission on the .pl file -- that did seem
> to make a difference, but I got a lot of what seemed to be compiling
> errors, and the test pn.com file was wrong, so I did it all again but
> did +x for *all* of the .pl files in source (but only those). I
> recompiled again, and still got what looks like errors - here is a sample:
>
> hsmith kochav 115> make
> Updating dependency file, this may take a little while
> g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g -o
> cddefines.h.gch cddefines.h
> g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o maincl.o
> maincl.cpp
> g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> abund_starburst.o abund_starburst.cpp
> g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> abundances.o abundances.cpp
> g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> age_check.o age_check.cpp
> g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> assert_results.o assert_results.cpp
> g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> atmdat_2photon.o atmdat_2photon.cpp
> g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> atmdat_3body.o atmdat_3body.cpp
> ....
> ....  [and the last lines]
>
> g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> zone_startend.o zone_startend.cpp
> ar ru libcloudy.a abund_starburst.o abundances.o age_check.o
> assert_results.o atmdat_2photon.o atmdat_3body.o atmdat_HS_caseb.o
> atmdat_adfa.o atmdat_char_tran.o atmdat_chianti.o atmdat_dielrec_fe.o
> atmdat_dielsupres.o atmdat_lamda.o atmdat_ligbar.o atmdat_lines_setup.o
> atmdat_outer_shell.o atmdat_readin.o atom_fe2ovr.o atom_feii.o
> atom_hyperfine.o atom_level2.o atom_level3.o atom_leveln.o atom_oi.o
> atom_pop2.o atom_pop3.o atom_pop5.o atom_seq_beryllium.o
> atom_seq_boron.o cddrive.o cdgetlinelist.o cdinit.o cdspec.o cloudy.o
> cont_createmesh.o cont_createpointers.o cont_ffun.o cont_gammas.o
> cont_gaunt.o cont_ipoint.o cont_negative.o cont_pump.o
> cont_setintensity.o container_classes.o conv_base.o conv_eden_ioniz.o
> conv_fail.o conv_init_solution.o conv_ioniz.o conv_itercheck.o
> conv_pres_temp_eden_ioniz.o conv_temp_eden_ioniz.o cool_alum.o
> cool_argo.o cool_calc.o cool_carb.o cool_chlo.o cool_chro.o cool_coba.o
> cool_dima.o cool_etc.o cool_eval.o cool_fluo.o cool_iron.o cool_magn.o
> cool_mang.o cool_neon.o cool_nick.o cool_nitr.o cool_oxyg.o cool_phos.o
> cool_pota.o cool_pr.o cool_punch.o cool_scan.o cool_sili.o cool_sodi.o
> cool_sulf.o cool_tita.o cool_vana.o cool_zinc.o cpu.o dense_fabden.o
> dense_tabden.o dynamics.o eden_sum.o grains.o grains_mie.o
> grains_qheat.o grid_do.o grid_xspec.o hash.o hcmap.o heat_punch.o
> heat_sum.o helike_cs.o helike_einsta.o helike_energy.o helike_recom.o
> highen.o hydro_bauman.o hydro_recom.o hydro_vs_rates.o hydrocollid.o
> hydroeinsta.o hydrolevel.o hydrooscilstr.o hydroreccool.o hydrot2low.o
> hypho.o init_coreload.o init_coreload_postparse.o
> init_defaults_preparse.o init_sim_postparse.o input.o ion_alumi.o
> ion_argon.o ion_beryl.o ion_boron.o ion_calci.o ion_carbo.o ion_chlor.o
> ion_chrom.o ion_cobal.o ion_collis.o ion_coppe.o ion_fluor.o
> ion_helium.o ion_iron.o ion_lithi.o ion_magne.o ion_manga.o ion_neon.o
> ion_nicke.o ion_nitro.o ion_oxyge.o ion_phosi.o ion_photo.o ion_potas.o
> ion_recomb.o ion_recomb_Badnell.o ion_scand.o ion_silic.o ion_sodiu.o
> ion_solver.o ion_sulph.o ion_titan.o ion_trim.o ion_vanad.o ion_zero.o
> ion_zinc.o iso_collide.o iso_continuum_lower.o iso_cool.o iso_create.o
> iso_error.o iso_ionize_recombine.o iso_level.o iso_photo.o
> iso_radiative_recomb.o iso_solve.o iter_end_chk.o iter_startend.o
> lines_service.o magnetic.o mean.o molcol.o mole_co_atom.o
> mole_co_drive.o mole_co_etc.o mole_co_reactions.o mole_co_solve.o
> mole_co_step.o mole_h2.o mole_h2_coll.o mole_h2_create.o mole_h2_etc.o
> mole_h2_form.o mole_h2_io.o mole_h_drive.o mole_h_step.o nemala.o
> nemala2.o opacity_add1element.o opacity_add1subshell.o
> opacity_addtotal.o opacity_createall.o opacity_zero.o optimize_do.o
> optimize_func.o optimize_phymir.o optimize_subplx.o parse_CMB.o
> parse_absmag.o parse_abundances.o parse_age.o parse_agn.o
> parse_atom_co.o parse_atom_h2.o parse_atom_iso.o parse_backgrd.o
> parse_blackbody.o parse_caseb.o parse_commands.o parse_compile.o
> parse_constant.o parse_coronal.o parse_cosmic_rays.o parse_crashdo.o
> parse_dlaw.o parse_dont.o parse_drive.o parse_element.o
> parse_extinguish.o parse_f_nu.o parse_fluc.o parse_globule.o
> parse_grain.o parse_grid.o parse_hden.o parse_init.o parse_interp.o
> parse_ionpar.o parse_map.o parse_metal.o parse_norm.o parse_optimize.o
> parse_plot.o parse_powerlawcontinuum.o parse_print.o parse_punch.o
> parse_radius.o parse_rangeoption.o parse_ratio.o parse_set.o
> parse_sphere.o parse_state.o parse_stop.o parse_table.o parse_test.o
> parse_tlaw.o parse_trace.o plot.o pressure_change.o pressure_total.o
> prt.o prt_alltau.o prt_columns.o prt_comment.o prt_continuum.o
> prt_final.o prt_header.o prt_linepres.o prt_lines.o
> prt_lines_continuum.o prt_lines_general.o prt_lines_grains.o
> prt_lines_helium.o prt_lines_hydro.o prt_lines_lv1_k_zn.o
> prt_lines_lv1_li_ne.o prt_lines_lv1_na_ar.o prt_lines_molecules.o
> prt_linesum.o prt_meanion.o prt_met.o prt_zone.o punch_average.o
> punch_colden.o punch_do.o punch_fits.o punch_line.o punch_linedata.o
> punch_opacity.o punch_special.o radius_first.o radius_increment.o
> radius_next.o rt_continuum_shield_fcn.o rt_diffuse.o rt_escprob.o
> rt_line_all.o rt_line_driving.o rt_line_one.o rt_line_one_tau_reset.o
> rt_line_one_tauinc.o rt_ots.o rt_recom_effic.o rt_stark.o rt_tau_inc.o
> rt_tau_init.o rt_tau_reset.o sanity_check.o service.o stars.o state.o
> temp_change.o thirdparty.o thirdparty_interpolate.o thirdparty_lapack.o
> vary_input.o warnings.o zero.o zone_startend.o
> ar: creating libcloudy.a
> ranlib libcloudy.a
> g++ -O3 -ftrapping-math -fno-math-errno -Wall -g -o cloudy.exe maincl.o
> -L. -lcloudy
> hsmith kochav 116>

That looks perfectly OK.

> I cannot tell if these are botched assets or not, but these are all the
> final lines.

I was asking about the final lines in the file pn.out, but I realize now
that it is not part of the test suite, so there will be no asserts in
there. So disregard that question.

Could you run the smoke test by creating an input file with the single
command

test

and run that. Could you then look if the code reports any problems at
the end of the output file?


Cheers,

Peter.

> --- On *Thu, 12/3/09, Peter van Hoof /<p.vanhoof@...>/* wrote:
>
>
>     From: Peter van Hoof <p.vanhoof@...>
>     Subject: Re: [cloudy_simulations] brand new user query
>     To: cloudy_simulations@yahoogroups.com
>     Date: Thursday, December 3, 2009, 10:53 AM
>
>
>
>     Hi,
>
>      > I have installed CLOUDY for the first time - c.08.00. Since I could
>      > not locate anyone at CfA running it to ask, I thought I'd post this
>      > very simple query here.
>      >
>      > I'm on a Linux machine running KDE. The "tar -xfz name.tar.gz"
>      > complained about the z, so I had to unzip it with just -xf. That
>      > seemed to go fine though. Then I ran "make" - and got the following
>      > message:
>
>     What Linux version is this? And what tar version do you have? Could you
>     give the output of
>
>     tar --version
>
>     I suspect that you have a very ancient Linux distribution.
>
>      > hsmith kochav 39> make make: execvp: ./precompile. pl: Permission
>      > denied Updating dependency file, this may take a little while make:
>      > execvp: ./precompile. pl: Permission denied g++ -ansi -O3
>      > -ftrapping-math -fno-math-errno -Wall -g -c -o maincl.o maincl.cpp
>      > g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g -c -o
>      > abund_starburst. o a bund_starburst. cpp g++ -ansi -O3
>     -ftrapping-math
>      > -fno-math-errno -Wall -g -c -o abundances.o abunda nces.cpp etc etc
>      > etc etc for many lines, ending with:
>
>     This sounds like the file ./precompile. pl has the wrong
>     permissions. Tar
>     should have done this right... But you can fix this with
>
>     chmod +x precompile.pl
>
>     in the source directory.
>
>      > warnings.o zero.o zone_startend. o ar: creating libcloudy.a ranlib
>      > libcloudy.a g++ -O3 -ftrapping-math -fno-math-errno -Wall -g -o
>      > cloudy.exe maincl.o -L. -lcloudy hsmith kochav 40>
>      >
>      > But in the end everything looked "normal." I ran the sample:
>      > cloudy.exe <pn.in >pn.out and got no errors. But when I plot ps.con,
>      > I do not quite get the nice credible results in Fig 1 of the
>      > quick-guide start: the continuum plunges down in the visible, and
>      > other quirks appear. There does not seem to be any Ne emission FS
>      > lines in the infrared.
>      >
>      > Can you help me sort things out a bit? Thanks.
>
>     Could you look at the end of the output file and tell us if there are
>     any reports of botched asserts?
>
>     Cheers,
>
>     Peter.
>
>     --
>     Peter van Hoof
>     Royal Observatory of Belgium
>     Ringlaan 3
>     1180 Brussel
>     Belgium
>     http://homepage. oma.be/pvh <http://homepage.oma.be/pvh>
>
>
>
>
>

--
Peter van Hoof
Royal Observatory of Belgium
Ringlaan 3
1180 Brussel
Belgium
http://homepage.oma.be/pvh

Hi,

> I have installed CLOUDY for the first time - c.08.00.  Since I could
> not locate anyone at CfA running it to ask, I thought I'd post this
> very simple query here.
>
> I'm on a Linux machine running KDE. The "tar -xfz name.tar.gz"
> complained about the z, so I had to unzip it with just -xf. That
> seemed to go fine though.  Then I ran "make" - and got the following
> message:

What Linux version is this? And what tar version do you have? Could you
give the output of

tar --version

I suspect that you have a very ancient Linux distribution.

> hsmith kochav 39> make make: execvp: ./precompile.pl: Permission
> denied Updating dependency file, this may take a little while make:
> execvp: ./precompile.pl: Permission denied g++ -ansi -O3
> -ftrapping-math -fno-math-errno -Wall -g   -c -o maincl.o maincl.cpp
> g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o
> abund_starburst.o a bund_starburst.cpp g++ -ansi -O3 -ftrapping-math
> -fno-math-errno -Wall -g   -c -o abundances.o abunda nces.cpp etc etc
> etc etc for many lines, ending with:

This sounds like the file ./precompile.pl has the wrong permissions. Tar
should have done this right... But you can fix this with

chmod +x precompile.pl

in the source directory.

> warnings.o zero.o zone_startend.o ar: creating libcloudy.a ranlib
> libcloudy.a g++ -O3 -ftrapping-math -fno-math-errno -Wall -g -o
> cloudy.exe maincl.o -L. -lcloudy hsmith kochav 40>
>
> But in the end everything looked "normal." I ran the sample:
> cloudy.exe <pn.in >pn.out and got no errors. But when I plot ps.con,
> I do not quite get the nice credible results in Fig 1 of the
> quick-guide start: the continuum plunges down in the visible, and
> other quirks appear.  There does not seem to be any Ne emission FS
> lines in the infrared.
>
> Can you help me sort things out a bit? Thanks.

Could you look at the end of the output file and tell us if there are
any reports of botched asserts?


Cheers,

Peter.

--
Peter van Hoof
Royal Observatory of Belgium
Ringlaan 3
1180 Brussel
Belgium
http://homepage.oma.be/pvh

Hi,

I'm trying to figure out an easy way to calculate with Cloudy the emission
measure of my observed lines.

In principle, I have almost all I need from a Cloudy calculation: the chemical
abundance, the ionic fraction and the radiative recombination coefficient. The
latter is produced by "punch recombination coefficients", and I can select the
one for the relevant ion. However, I still need to 'weight' this emission
measure with the fraction of recombinations which actually leads to the
transition I'm interested to.

For example, take the forbidden line of the OVII Kalpha triplet. I can get the
total recombination coefficient for OVII from the output of "punch
recombination" (although it is not clear to me the difference between the value
listed after 'He-like O   8', and the one listed for each zone and for each ion:
the two are similar, but different). Then I could use the normal output to
weight the forbidden line with respect to the other intense lines from OVII in
that run. But I have no direct information on the radiative recombination
continuum. I think it should be counted. Is there any other way to have the
correction to the recombination coefficient for a particular transition?

Apart from the calculation of the emission measure, the direct estimate of the
flux of RRCs would be interesting. I couldn't find any means to do that in
Cloudy, unless I produce a synthetic spectrum and evaluate the flux from it. Is
there a way to extract the flux of RRCs directly from the calculations, as for
the emission lines?

Thank you,

Stefano

Hello all,

I am trying to use Cloudy to study the dissociation rate of H2 due to a
background (blackbody) source. I was wondering if there is a way to use a
blackbody SED but force the shape to go to zero above a certain wavelength.

Also, as I have been looking through Hazy, I have found a command to write out a
bunch of information about H2 (punch H2 destruction rates), is there another
document to look at to understand all that it is outputting?

Thanks,
William Gray

I have installed CLOUDY for the first time - c.08.00.  Since I could not locate
anyone at CfA running it to ask, I thought I'd post this very simple query here.

I'm on a Linux machine running KDE. The "tar -xfz name.tar.gz" complained about
the z, so I had to unzip it with just -xf. That seemed to go fine though.  Then
I ran "make" - and got the following message:

hsmith kochav 39> make
make: execvp: ./precompile.pl: Permission denied
Updating dependency file, this may take a little while
make: execvp: ./precompile.pl: Permission denied
g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o maincl.o
maincl.cpp
g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o abund_starburst.o
a
bund_starburst.cpp
g++ -ansi -O3 -ftrapping-math -fno-math-errno -Wall -g   -c -o abundances.o
abunda
nces.cpp
etc etc etc etc for many lines, ending with:

warnings.o zero.o zone_startend.o
ar: creating libcloudy.a
ranlib libcloudy.a
g++ -O3 -ftrapping-math -fno-math-errno -Wall -g -o cloudy.exe maincl.o -L.
-lcloudy
hsmith kochav 40>

But in the end everything looked "normal."
I ran the sample: cloudy.exe <pn.in >pn.out and got no errors.
But when I plot ps.con, I do not quite get the nice credible results in Fig 1 of
the quick-guide start: the continuum plunges down in the visible, and other
quirks appear.  There does not seem to be any Ne emission FS lines in the
infrared.

Can you help me sort things out a bit? Thanks.

Hello,

first of all, thanks a lot for the recent help with my problem with the incident
continuum.

I'd like to report two more problems that I have encountered and ask for advice.

1) I have tried to run scripts using the aperture command. I assumed that they
would notably change the net transmitted spectrum, but find that the output of
"punch continuum" with and without the aperture command is exactly the same. Is
this intended, and did I understand the command incorrectly, or is there some
other underlying problem? Some clarification on the proper usage and what is
expected to change using the aperture would be greatly appreciated.

2) I started incorporating the ISM abundances into my scripts, and find that if
I make the distance of the inward face of the cloud to the central source small
enough, I get an assert thrown and the error message following below.The assert
occurs e.g. for a radius of 1e-3 linear parsecs and a density of 1cm^-3, or 1e-5
linear parsecs and a density of 1000 cm^-3.
I assume the reason for this might be that if the cloud starts too close to an
ionizing source, they are evaporated, and maybe that causes problems?

The error message below also includes the input script used in both cases, in
the first case once with and once without the aperture beam command uncommented.

Thanks a lot for your help,

    Daniela

Error Message:

  PROBLEM DISASTER An assert has been thrown, this is bad.
  It happened in the file grains.cpp at line number 3724
  This is iteration 1, nzone 0, fzone 0.76, lgSearch=T.



            vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
           > PROBLEM DISASTER PROBLEM DISASTER.      <
           > Sorry, something bad has happened.      <
           > Please post this on the Cloudy web site <
           > discussion board at www.nublado.org     <
           > Please send all following information:  <
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


  Cloudy version number is 08.00
  cdInit compiled on Jun 10 2009 in OS Linux (AMD64) using the g++ 40102 compiler
in LP64 mode.

     0 warnings,  0 cautions,  0 temperature failures.  Messages follow.
  Input commands follow:
c ======================
luminosity 39
c
interpolate (8.55604 1.2839)
continue (9.39006 1.16525)
continue (9.95446 1.18009)
continue (10.2341 1.04661)
continue (11.2429 0.898305)
continue (11.4128 1.0911)
continue (13.4262 1.87712)
continue (13.7913 2.48517)
continue (14.2814 3.36017)
continue (14.4064 3.58263)
continue (14.5415 3.89407)
continue (14.9214 4.35381)
continue (14.9865 4.53178)
continue (15.1314 4.72458)
continue (15.2965 4.97669)
continue (15.4262 4.7839)
continue (15.5508 4.50212)
continue (16.7018 0.586864)
continue (16.7618 0.705509)
continue (16.8568 0.75)
continue (16.9167 0.824153)
continue (17.0067 0.868644)
continue (17.0766 0.898305)
continue (17.1615 0.898305)
continue (17.2364 0.853814)
continue (17.3363 0.76483)
continue (17.436 0.616526)
continue (17.5258 0.45339)
continue (17.6006 0.260594)
continue (17.6505 0.112287)
continue (17.7302 -0.0805082)
continue (17.8101 -0.169492)
continue (17.9249 -0.273305)
continue (18.0946 -0.406779)
continue (18.6189 -0.67373)
continue (18.9933 -0.866525)
continue (19.3079 -1.02966)
continue (19.5575 -1.20763)
continue (19.7122 -1.40042)
continue (19.8319 -1.54873)
continue (19.9267 -1.71186)
continue (20.0464 -1.91949)
continue (20.2011 -2.2161)
continue (20.3456 -2.6017)
continue (20.4503 -2.88348)
continue (20.5849 -3.32839)
continue (20.7344 -3.68432)
continue (20.9091 -3.89195)
continue (21.2283 -4.60381)
continue (21.947 -5.34534)
c
abundances ism
hden 1 linear
c aperture beam
diffuse ots
constant density
distance 2000 linear parsecs
radius 1e-3 linear parsecs
stop efrac=0.05
c
c Output Commands
punch continuum unit file="cygx1_grains.cont"
punch overview file="cygx1_grains.ovr"
punch results "cygx1_grains.res"
c ======================

Hi Gary,

Thanks a lot, I'll try it tomorrow and let you know.
Best regards,
Christophe

--- In cloudy_simulations@yahoogroups.com, "Gary Ferland" <gjferland@...> wrote:
>
> Hi Christophe
>
> this was a bug and is fixed in the development version.  I also added the
every option to the other two sets of commands.
>
> thanks for the help,
> Gary
>

Greetings,

It is our intention to release a new version of Cloudy every two years.  We are
approaching the 2-year anniversary of C08 and are making plans for the C10
release.

Now would be a good time to let us know of any serious problems with C08 that
have not been posted on this group.  If you have a problem with a particular
simulation don't forget to post enough information for us to run the sim
ourselves.

good luck,
Gary

Hi Christophe

this was a bug and is fixed in the development version.  I also added the every
option to the other two sets of commands.

thanks for the help,
Gary

Hi Stefano,

I have committed the changes. They should be in the next release.

Thanks again for the help!

Peter.


> I calculated the temperatures at 10^5 K, with the CHIANTI IDL
> routines. This is outside the range where the cs are actually
> evaluated in CHIANTI, but they told me that the extrapolation
> shouldn't be quite good. In any case, the values for the cs are quite
> similar for temperatures lower than 10^5 and for temperatures not
> much higher.
>
> Stefano
>
> --- In cloudy_simulations@yahoogroups.com, Peter van Hoof
> <p.vanhoof@...> wrote:
>> Hi Stefano,
>>
>> I am finally getting around to incorporating this into Cloudy. I
>> will move the M2 line into level1.dat so that we don't have to
>> delete a line from level2.dat. I have one question: how did you
>> calculate the collision strengths? Did you use a fixed temperature,
>> or did you average over a range, and what were the temperature
>> values?
>>
>>
>> Cheers,
>>
>> Peter.
>>
>> burkinafaso76 wrote:
>>> The updated level2.dat file is in the 'Files' section. Let me
>>> know if it is ok and if you need more detailed comments for the
>>> changes.
>>>
>>> Stefano
>>>
>>> --- In cloudy_simulations@yahoogroups.com, Peter van Hoof
>>> <p.vanhoof@> wrote:
>>>> Hi Stefano,
>>>>
>>>>> I have a new level2.dat file, with the 6 main FeXVII
>>>>> transitions included and updated. All the data are from
>>>>> CHIANTI, including the collision strengths (directly
>>>>> calculated with their code). I made some tests, and it seems
>>>>> to work as it should.
>>>>>
>>>>> I can send you the file, if you are interested.
>>>> Sure, anything that improves the data in Cloudy is welcome!
>>>>
>>>> Peter.
>>>>
>>>>> Cheers,
>>>>>
>>>>> Stefano
>>>>>
>>>>> --- In cloudy_simulations@yahoogroups.com, Peter van Hoof
>>>>> <p.vanhoof@> wrote:
>>>>>> Hi Stefano,
>>>>>>
>>>>>>
>>>>>>>> If you enter a negative number in the cs1 field, the
>>>>>>>> absolute value will be used directly as the collision
>>>>>>>> strength without using the g-bar approximation. That
>>>>>>>> would be the appropriate thing to do if you have better
>>>>>>>> calculated CS.
>>>>>>>>
>>>>>>> while it is clear to me that a negative number is a flag
>>>>>>> to use the absolute value and not the approximation, I
>>>>>>> don't understand the meaning of the positive values. They
>>>>>>> do not seem simple flags, because their values are in
>>>>>>> some way used to decide the kind of approximation to
>>>>>>> adopt. Otherwise, why are they so different from
>>>>>>> transition to transition?
>>>>>> The meaning of the positive values is largely opaque to me
>>>>>> as well. It appears that the number is a code for which
>>>>>> g-bar approximation to use. It is not a scaling factor, or
>>>>>> anything like that. My advise would be to stay away from
>>>>>> that. This is the kind of cruft that we would love to get
>>>>>> rid of, but it takes time to get a suitable replacement...
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Peter.
>>>>>>
>>>>>> -- Peter van Hoof Royal Observatory of Belgium Ringlaan 3
>>>>>> 1180 Brussel Belgium http://homepage.oma.be/pvh
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------
>>>>>
>>>>> Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>> -- Peter van Hoof Royal Observatory of Belgium Ringlaan 3 1180
>>>> Brussel Belgium http://homepage.oma.be/pvh
>> -- Peter van Hoof Royal Observatory of Belgium Ringlaan 3 1180
>> Brussel Belgium http://homepage.oma.be/pvh
>>

--
Peter van Hoof
Royal Observatory of Belgium
Ringlaan 3
1180 Brussel
Belgium
http://homepage.oma.be/pvh

Hi Peter,

I calculated the temperatures at 10^5 K, with the CHIANTI IDL routines. This is
outside the range where the cs are actually evaluated in CHIANTI, but they told
me that the extrapolation shouldn't be quite good. In any case, the values for
the cs are quite similar for temperatures lower than 10^5 and for temperatures
not much higher.

Stefano

--- In cloudy_simulations@yahoogroups.com, Peter van Hoof <p.vanhoof@...> wrote:
>
> Hi Stefano,
>
> I am finally getting around to incorporating this into Cloudy. I will
> move the M2 line into level1.dat so that we don't have to delete a line
> from level2.dat. I have one question: how did you calculate the
> collision strengths? Did you use a fixed temperature, or did you average
> over a range, and what were the temperature values?
>
>
> Cheers,
>
> Peter.
>
> burkinafaso76 wrote:
> > The updated level2.dat file is in the 'Files' section.
> > Let me know if it is ok and if you need more detailed comments for the
changes.
> >
> > Stefano
> >
> > --- In cloudy_simulations@yahoogroups.com, Peter van Hoof <p.vanhoof@>
wrote:
> >> Hi Stefano,
> >>
> >>> I have a new level2.dat file, with the 6 main FeXVII transitions
> >>> included and updated. All the data are from CHIANTI, including the
> >>> collision strengths (directly calculated with their code). I made
> >>> some tests, and it seems to work as it should.
> >>>
> >>> I can send you the file, if you are interested.
> >> Sure, anything that improves the data in Cloudy is welcome!
> >>
> >> Peter.
> >>
> >>> Cheers,
> >>>
> >>> Stefano
> >>>
> >>> --- In cloudy_simulations@yahoogroups.com, Peter van Hoof
> >>> <p.vanhoof@> wrote:
> >>>> Hi Stefano,
> >>>>
> >>>>
> >>>>>> If you enter a negative number in the cs1 field, the absolute
> >>>>>> value will be used directly as the collision strength without
> >>>>>> using the g-bar approximation. That would be the appropriate
> >>>>>> thing to do if you have better calculated CS.
> >>>>>>
> >>>>> while it is clear to me that a negative number is a flag to use
> >>>>> the absolute value and not the approximation, I don't understand
> >>>>> the meaning of the positive values. They do not seem simple
> >>>>> flags, because their values are in some way used to decide the
> >>>>> kind of approximation to adopt. Otherwise, why are they so
> >>>>> different from transition to transition?
> >>>> The meaning of the positive values is largely opaque to me as well.
> >>>> It appears that the number is a code for which g-bar approximation
> >>>> to use. It is not a scaling factor, or anything like that. My
> >>>> advise would be to stay away from that. This is the kind of cruft
> >>>> that we would love to get rid of, but it takes time to get a
> >>>> suitable replacement...
> >>>>
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Peter.
> >>>>
> >>>> -- Peter van Hoof Royal Observatory of Belgium Ringlaan 3 1180
> >>>> Brussel Belgium http://homepage.oma.be/pvh
> >>>>
> >>>
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>> Yahoo! Groups Links
> >>>
> >>>
> >>>
> >> --
> >> Peter van Hoof
> >> Royal Observatory of Belgium
> >> Ringlaan 3
> >> 1180 Brussel
> >> Belgium
> >> http://homepage.oma.be/pvh
>
> --
> Peter van Hoof
> Royal Observatory of Belgium
> Ringlaan 3
> 1180 Brussel
> Belgium
> http://homepage.oma.be/pvh
>

Hi Stefano,

I am finally getting around to incorporating this into Cloudy. I will
move the M2 line into level1.dat so that we don't have to delete a line
from level2.dat. I have one question: how did you calculate the
collision strengths? Did you use a fixed temperature, or did you average
over a range, and what were the temperature values?


Cheers,

Peter.

burkinafaso76 wrote:
> The updated level2.dat file is in the 'Files' section.
> Let me know if it is ok and if you need more detailed comments for the
changes.
>
> Stefano
>
> --- In cloudy_simulations@yahoogroups.com, Peter van Hoof <p.vanhoof@...>
wrote:
>> Hi Stefano,
>>
>>> I have a new level2.dat file, with the 6 main FeXVII transitions
>>> included and updated. All the data are from CHIANTI, including the
>>> collision strengths (directly calculated with their code). I made
>>> some tests, and it seems to work as it should.
>>>
>>> I can send you the file, if you are interested.
>> Sure, anything that improves the data in Cloudy is welcome!
>>
>> Peter.
>>
>>> Cheers,
>>>
>>> Stefano
>>>
>>> --- In cloudy_simulations@yahoogroups.com, Peter van Hoof
>>> <p.vanhoof@> wrote:
>>>> Hi Stefano,
>>>>
>>>>
>>>>>> If you enter a negative number in the cs1 field, the absolute
>>>>>> value will be used directly as the collision strength without
>>>>>> using the g-bar approximation. That would be the appropriate
>>>>>> thing to do if you have better calculated CS.
>>>>>>
>>>>> while it is clear to me that a negative number is a flag to use
>>>>> the absolute value and not the approximation, I don't understand
>>>>> the meaning of the positive values. They do not seem simple
>>>>> flags, because their values are in some way used to decide the
>>>>> kind of approximation to adopt. Otherwise, why are they so
>>>>> different from transition to transition?
>>>> The meaning of the positive values is largely opaque to me as well.
>>>> It appears that the number is a code for which g-bar approximation
>>>> to use. It is not a scaling factor, or anything like that. My
>>>> advise would be to stay away from that. This is the kind of cruft
>>>> that we would love to get rid of, but it takes time to get a
>>>> suitable replacement...
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Peter.
>>>>
>>>> -- Peter van Hoof Royal Observatory of Belgium Ringlaan 3 1180
>>>> Brussel Belgium http://homepage.oma.be/pvh
>>>>
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>> --
>> Peter van Hoof
>> Royal Observatory of Belgium
>> Ringlaan 3
>> 1180 Brussel
>> Belgium
>> http://homepage.oma.be/pvh

--
Peter van Hoof
Royal Observatory of Belgium
Ringlaan 3
1180 Brussel
Belgium
http://homepage.oma.be/pvh

In the Hazy manual, I saw the following

14.38.14. punch ionizing continuum [options]
This creates a file that can be used to indicate ionization sources.  If the
keyword every occurs then this is punched for every zone,otherwise it is only
punched for the last zone.

I tried it, but had only the continuum at the last step. Is there any bug here?
BTW, could it be possible to also have the "every" option applying for the
"punch total opacity" and "punch optical depth" commands?

Thanks a lot,
Christophe

Hello,

I have recently started using cloudy and am now trying to use it to model the
effect of a blackhole binary on the environment.
I am using an incident continuum of the order of 10^36 erg/s, and the
interpolate command to define the spectrum.
However, the code breaks with a warning and an error message: the warning states
that the incident continuum is too intense.
This seems odd to me since 10^36 erg/s is only about 1000 times solar.

I think the error that actually causes the code to break may be related to this
(if I decrease the total luminosity or increase the radius, the code runs
without breaking). The output states

"PROBLEM RT_line_static called with large negative optical depth, zone 2.00,
setting lgAbort true.
    Cl17 3.21A Te1.01e+07 eden1.2e+00 CS0.00e+00 Aul6.3e+10 Tex1.23e+06
cool0.0e+00 het0.0e+00 conopc1.2e-34 albdo1.00e+00
   Tin-2.2e+05 Tout1.7e+11 Esc9.7e-01 eEsc1.1e-03 DesP3.4e-05 Pump2.8e-04
OTS8.2e-25 PopL,U 2.9e-10 2.0e-24 PopOpc5.5e-17
[...]
  W-Calculation stopped because calculation aborted. Iteration  1 of 1
    The geometry is plane-parallel.
  W-Calculation stopped because calculation aborted.
  W-This was not intended.
  W-The calculation aborted.  Something REALLY went wrong! "

Any hints on how to avoid this to happen would be greatly appreciated!
The input file is attached as hII_j1118.in

Many thanks,

    Daniela Huppenkothen

Hi Rob,

Alternatively, if neither Starburst99 or PopStar suit your needs, you
can fairly easily incorporate other grids by making your own .ascii
file. A full description of the format is in the file
vanhoof_atmosphere_grids.pdf in the docs directory.

Cheers,

Peter.

> You can use Starburst99 and PopStar SSPs at least. See the wiki:
>
> http://wiki.nublado.org/wiki/StellarAtmospheres
>
>            Cheers,
>               Jarle.
>
> On Fri, Nov 6, 2009 at 2:36 PM, wiersmarp <wiersma@...
> <mailto:wiersma@...>> wrote:
>
>
>
>     Hi there,
>
>     I was looking over the 'table stars' command, and it wasn't
>     completely clear to me whether there are input spectra only for
>     single stars or for SSPs too.
>
>     Alternatively I can make some grids using GALAXEV (Bruzual and
>     Charlot) or something, but it there is something already in CLOUDY,
>     it decreases the chances of me doing something wrong ;).
>
>     Peace,
>     Rob Wiersma

--
Peter van Hoof
Royal Observatory of Belgium
Ringlaan 3
1180 Brussel
Belgium
http://homepage.oma.be/pvh