[Mesa-users] other_wind
Croxmor Moraga
rodrigo.moraga.merino at gmail.com
Tue Oct 22 17:42:39 EDT 2019
I owe you a lot Warrick, and all of you mesa-users as well. It worked, it
finally worked.
I had to define my surface gravity, I had a little more issues with the
units, but I had already solved it.
The only thing that is in my mind now is that: if should I use the
photosphere radius and luminosity, etc. Or the ones directly from the
surface, which I used in the end.
Once again thank you all for your help, if you want the code to implement
it in the other_wind template, which is null, unfortunately. Or do you want
more information on what I did? just ask.
Thanks and goodnight, afternoon, morning.
El mar., 22 oct. 2019 a las 5:53, Warrick Ball (<W.H.Ball at bham.ac.uk>)
escribió:
> Hi again,
>
> The simplest way to start debugging something like this is to write the
> value of your wind to the screen at the end of your subroutine. If you do
> this, you'll see that it's NaN. So clearly something is going wrong!
>
> I then wrote to the screen all the components you use in this formula:
>
> w = 4d-13*(L1/(s% grav(1)*R1))/(Lsun/((10**loggsol)*Rsun)) ! in
> Msun/year
>
> The NaN comes from `s% grav(1)`. Why is that? Well, the notes in the
> template (which you have copied into your routine) say
>
> ! NOTE: don't assume that vars are set at this point.
> ! so if you want values other than those given as args,
> ! you should use values from s% xh(:,:) and s% xa(:,:) only.
> ! rather than things like s% Teff or s% lnT(:) which have not been
> set yet.
>
> So the problem is that you're using `s% grav` before it's been assigned a
> value. But it can be derived from Msurf and Rsurf, which are passed as
> arguments to the subroutine. If you do this, your wind routine should
> work.
>
> If you've chosen the surface boundary condition for your stellar model
> such that the outermost mesh point is not the photosphere and you need the
> quantities at the photosphere, you can try copying the subroutine
> `get_phot_info` from `star/private/star_utils.f90` into your
> `run_star_extras.f`. (I'm not sure if other users have a better way of
> doing this. I'm also not promising that will work because
> `get_photo_info` also uses derived information that might not have been
> set yet.)
>
> Cheers,
> Warrick
>
>
>
>
> ------------
> Warrick Ball
> Postdoc, School of Physics and Astronomy
> University of Birmingham, Edgbaston, Birmingham B15 2TT
> W.H.Ball at bham.ac.uk
> +44 (0)121 414 4552
>
>
> On Tue, 22 Oct 2019, rodrigo.moraga.merino at gmail.com wrote:
>
> > Thanks, Warrick, it worked and now my code compiles and the run keeps
> going.
> > But the mdot doesn't change. It remains at zero.
> > I believe it should be because I defined something wrong at the end of
> my subroutine, and my subroutine doesn't connect properly with the rest of
> the wind .f90.
> > Someone may know what can I do to fix that? (attached the new version of
> my run_star_extras.f)
> > From beforehand, thank you all.
> >
> > El lun., 21 oct. 2019 a las 6:31, Warrick Ball (<W.H.Ball at bham.ac.uk>)
> escribió:
> > Hi Croxmor,
> >
> > In Fortran, variables must be declared before any actual code.
> Your
> > `run_star_extras.f` has a mixture. So the first thing is to move
> all of
> > the variable declarations before any code. That is, all the lines
> like
> > `real(dp) ...`, `integer ...` etc have to come before calculations
> or
> > assignments (like `ierr = 0` or `call star_ptr...` etc).
> >
> > I expect you'll then run into a few other errors because your
> extra wind
> > routine has diverged from the template bundled with r11701.
> First, you've
> > added the extra input integer `id_extra`, which shouldn't be there
> (and
> > isn't used anyway). Second, you've dropped the `intent(out)`
> attribute
> > from `ierr`.
> >
> > If you fix these, the code should compile.
> >
> > Cheers,
> > Warrick
> >
> >
> >
> >
> > ------------
> > Warrick Ball
> > Postdoc, School of Physics and Astronomy
> > University of Birmingham, Edgbaston, Birmingham B15 2TT
> > W.H.Ball at bham.ac.uk
> > +44 (0)121 414 4552
> >
> >
> > On Sun, 20 Oct 2019, mesa-users at lists.mesastar.org wrote:
> >
> > > You are right, here is the actual version of the
> run_star_extras.f and the message printed by the terminal is:
> > > gfortran -Wno-uninitialized -fno-range-check -fmax-errors=7
> -fprotect-parens -fno-sign-zero -fbacktrace -ggdb -finit-real=snan
> -fopenmp -fbounds-check -Wuninitialized -Warray-bounds -ggdb
> > -ffree-form -x
> > > f95-cpp-input -I/home/rodrigo/mesa-r11701/include
> -I/home/rodrigo/mesasdk/include -c ../src/run_star_extras.f
> > > ../src/run_star_extras.f:79:82:
> > >
> > > real(dp), intent(in) :: Lsurf, Msurf, Rsurf, Tsurf !
> surface values (cgs)
> > >
> 1
> > > Error: Unexpected data declaration statement at (1)
> > > ../src/run_star_extras.f:86:73:
> > >
> > > hot_wind, cool_wind, H_env_mass, H_He_env_mass,
> He_layer_mass
> > >
> 1
> > > Error: Unexpected data declaration statement at (1)
> > > ../src/run_star_extras.f:87:44:
> > >
> > > logical, parameter :: dbg = .false.
> > > 1
> > > Error: Unexpected data declaration statement at (1)
> > > ../src/run_star_extras.f:88:85:
> > >
> > > character (len=strlen) :: message, cool_wind_scheme,
> hot_wind_scheme, scheme
> > >
> 1
> > > Error: Unexpected data declaration statement at (1)
> > > ../src/run_star_extras.f:89:67:
> > >
> > > logical :: is_infalling, using_wind_scheme_mdot,
> use_other
> > >
> 1
> > > Error: Unexpected data declaration statement at (1)
> > > ../src/run_star_extras.f:90:73:
> > >
> > > real(dp), parameter :: Zsolar = 0.019d0 ! for Vink et
> al formula
> > >
> 1
> > > Error: Unexpected data declaration statement at (1)
> > > ../src/run_star_extras.f:92:80:
> > >
> > > real(dp), intent(out) :: w ! wind in units of
> Msun/year (value is >= 0)
> > >
> 1
> > > Error: Unexpected data declaration statement at (1)
> > > compilation terminated due to -fmax-errors=7.
> > > make: ***
> [/home/rodrigo/mesa-r11701/star/work_standard_makefile:38:
> run_star_extras.o] Error 1
> > >
> > > FAILED
> > >
> > > El dom., 20 oct. 2019 a las 9:44, Aaron Dotter (<
> aaron.dotter at gmail.com>) escribió:
> > > In order to help you we will need the code that gives the
> error message, not just the error message.
> > >
> > > Also please copy and paste the text from the terminal into your
> email rather than sending a screenshot.
> > >
> > >
> > >
> > > On Sat, Oct 19, 2019 at 10:00 PM Croxmor Moraga <
> rodrigo.moraga.merino at gmail.com> wrote:
> > > I included the command you gave me, but that only gave me
> another compilation error, the error now appears when I declare other
> variables I use: as it can be seen here:
> > > Do I have to change the declarations that I was using until now,
> or don't use it at all?
> > > Thanks for your consideration.
> > >
> > > El sáb., 19 oct. 2019 a las 22:06, Croxmor Moraga (<
> rodrigo.moraga.merino at gmail.com>) escribió:
> > > Thanks, I'll check it out. The idea is that loggsol is a
> constant defined in const.f90
> > >
> > > El jue., 17 oct. 2019 a las 16:42, Aaron Dotter (<
> aaron.dotter at gmail.com>) escribió:
> > > In order to access variables stored in the star derived
> type (s), you have to do this:
> > > call star_ptr(id, s, ierr)
> > >
> > > at the top of your other_ routine. See
> > >
> > >
> http://mesa.sourceforge.net/run_star_extras.html#activate-run_star_extrasf
> > >
> > > for more information about how to do this. I would also point
> out that I couldn't find anywhere that you set a value to "loggsol" so it's
> being used without being set.
> > >
> > >
> > > Aaron
> > >
> > >
> > > On Thu, Oct 17, 2019 at 3:37 PM Croxmor Moraga <
> rodrigo.moraga.merino at gmail.com> wrote:
> > > Here it is. My bad.
> > >
> > > El jue., 17 oct. 2019 a las 16:33, Aaron Dotter (<
> aaron.dotter at gmail.com>) escribió:
> > > (I have attached my run_star_extras.f and the inlist
> mentioned before. On MESA version: )
> > >
> > >
> > > There is no run_star_extras.f attached.
> > >
> > >
> > >
> > >
> > > El mié., 16 oct. 2019 a las 0:01, Josiah Schwab (<
> jwschwab at ucsc.edu>) escribió:
> > > Hi Croxmor,
> > >
> > > > But when I saw the other_wind.f90 code file, it didn't
> give me an example
> > > > of how to add a new wind scheme to the cool_wind_rgb;
> the only thing I want
> > > > to do, is to replace the original wind equation of one
> of the default
> > > > schemes, and use another version of that one.
> > > > So my problem is, from all the different routines and
> subroutines defined
> > > > en wind.f90; which one should I take and put in my
> run_star_extra file as a
> > > > subroutine?
> > > > When I only want to add a new scheme for the
> cool_wind_rgb without changing
> > > > anything else?
> > > > Here I attached the wind.f90 file for faster revision.
> > >
> > > I believe you can provide your other routine in
> run_star_extras and then set
> > >
> > > cool_wind_RGB_scheme = 'other'
> > >
> > > to only apply it in that case.
> > >
> > > Josiah
> > >
> > > _______________________________________________
> > > mesa-users at lists.mesastar.org
> > > https://lists.mesastar.org/mailman/listinfo/mesa-users
> > >
> > >
> > >
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20191022/5f34c021/attachment-0001.html>
More information about the Mesa-users
mailing list