[mesa-users] a problem about using the ZAMS models
Willie Strickland
cwskas at gmail.com
Mon Mar 18 17:39:49 EDT 2013
I always run from my own work directory as recommended by others on the list and in the getting started. Therefore, I am in the habit of copying any starting model, customized column or profile list, etc to my work directory.
While it may not be necessary, it is a habit pattern that works for me. I zip a succesful model, test, etc and archive it to refer to later if necessary or duplicate and use again. I always know that I have all the necessary files that I used in the original test when I reuse one of these archives.
Below I have added ==> to indicate the three options, one of which should be used.
I also keep copies of ~/mesa/star/defaults/
pgstar.defaults
controls.defaults
history_columns.list
profile_columns.list
star_job.defaults
open in a text editor most of the time while working so I can reference them.
Willie
from ~/mesa/star/defaults/star_job.defaults
line 110 in my installation
! starting model
! by default at the start of a run a zams starting model is loaded,
! and then the initial_mass, initial_z, and initial_y are adjusted as necessary.
! however, there are alternatives. you can use a model you saved previously,
! or you can request the system to create a pre-main-sequence model.
! btw: the system finds the zams file by using the control called 'zams_filename'
! the default zams file is for Z=0.02 and lives in data/star_data/zams_models.
! you can create your own zams file and use it instead -- see test_suite/create_zams.
==> load_saved_model = .false.
==> saved_model_name = 'undefined'
! if load_saved_model is true, then use this initial model
==> create_pre_main_sequence_model = .false.
! if true, the code will create a starting model with uniform composition,
! a core temperature below 10^6 so no nuclear burning,
! and uniform contraction for enough luminosity to make it fully convective.
==> create_initial_model = .false. ! this is an alternative to create_pre_main_sequence_model
! creates an adiabatic, contracting model for given mass and radius
! assumes no nuclear burning and constant entropy. ignores radiation pressure.
On Mar 18, 2013, at 7:16 AM, "WU T." <ggwutao at 126.com> wrote:
>
> Hi everyone,
> I encounter a problem about using the ZAMS models. I hope get some advice from you for the problem.
> I create many ZAMS models with different metallicity, such as, z=4d-2, 3d-2, 1d-2, and copy they to the directory mesa/data/star_data/zams_models and title zams_z4m2.data, zams_z3m2.data and zams_z1m2.data, respectively. Afterwards, do
> cd mesa/
> ./clean
> ./mk
> cd worh/
> change the metallicity z=4d-2, set the create_pre_main_sequence_model = .false.
> and do
> ./mk
> ./rn
> the terminal output as follow:
> '
> WARNING: requested initial_z does not match zams file initial_z.
>
>
>
> failed in get_zams_model
> star_load_zams ierr -1
>
> do_load1_star ierr -1
>
> '
> What should I do?
>
> Thx
>
>
>
>
>
> At 2013-03-13 18:40:32,mesa-users-request at lists.sourceforge.net wrote:
> >Send mesa-users mailing list submissions to
> > mesa-users at lists.sourceforge.net
> >
> >To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.sourceforge.net/lists/listinfo/mesa-users
> >or, via email, send a message with subject or body 'help' to
> > mesa-users-request at lists.sourceforge.net
> >
> >You can reach the person managing the list at
> > mesa-users-owner at lists.sourceforge.net
> >
> >When replying, please edit your Subject line so it is more specific
> >than "Re: Contents of mesa-users digest..."
> >
> >
> >Today's Topics:
> >
> > 1. Re: another MESA adipls installation problem (Bill Paxton)
> > 2. MESA SDK installation problem (Nadine Nettelmann)
> > 3. Re: MESA SDK installation problem (Richard Townsend)
> > 4. MESA sourceforge upgrade and new svn repository (Aaron Dotter)
> > 5. mesa/star problem with ifort 12.0.4 (Bill Paxton)
> > 6. Re: mesa/star problem with ifort 12.0.4 (Rob.Farmer)
> >
> >
> >----------------------------------------------------------------------
> >
> >Message: 1
> >Date: Fri, 8 Mar 2013 09:18:51 -0800
> >From: Bill Paxton <paxton at kitp.ucsb.edu>
> >Subject: Re: [mesa-users] another MESA adipls installation problem
> >To: Nadine Nettelmann <nadine.nettelmann at uni-rostock.de>
> >Cc: "mesa-users at lists.sourceforge.net"
> > <mesa-users at lists.sourceforge.net>
> >Message-ID: <AB497515-BD8E-42EF-BA5D-1ADC3B991E86 at kitp.ucsb.edu>
> >Content-Type: text/plain; charset=us-ascii
> >
> >Hi Nadine,
> >
> >Take a quick look at mesa/adipls/test/ck
> >
> >That's the script that is run to check the installation.
> >I'm guessing that your failure is happening from there.
> >
> >This is the line in the script that creates amdl.mesa:
> >
> >fgong-amdl.d Gemma.fgong amdl.mesa > .list
> >
> >Gemma.fgong should be part of the download;
> >the fgong-amdl.d script is part of adipls -- it converts
> >from fgong to the adipls "amdl" formal.
> >
> >I suggest trying to do the operations from the ck script
> >one at a time from the command line to see where things
> >go bad.
> >
> >Good luck,
> >Bill
> >
> >
> >
> >
> >
> >
> >On Mar 7, 2013, at 11:23 PM, Nadine Nettelmann wrote:
> >
> >> Hi MESA-installation experts ;-)
> >>
> >> with the hint by Rob Farmer (many thanks) I could get a little bit further in the installation
> >> of the adipls module, but the next error message is:
> >>
> >> At line 61 of file ../gensr/ofiles.c.f
> >> Fortran runtime error: Cannot read from file opened for WRITE
> >>
> >> *************************************************************
> >> In this version, the maximum number of mesh points is 20000
> >> Maximum number of modes for internal storage is 20000
> >> *************************************************************
> >> --------------------------------------------------
> >> Entering adipls with parameter passing
> >> i_paramset = 0
> >>
> >> Files needed:
> >> Model input on unit imlds (default 2)
> >> Trial frequency input on unit itrds (default 10). Optional.
> >> Grand summary on unit idsgsm (default 11).
> >> Short summary on unit idsssm (default 15).
> >> Eigenfunction on unit idsefn (default 4) (optional).
> >> Rotational kernel on unit idsrkr (default 12) (optional).
> >> Gamma1 kernel on unit idsgkr (default 13) (optional).
> >> Printed output on unit istdpr, if not default
> >> Input format: <unit number> <file name>
> >> input ends with EOF or a line containing -1.
> >> if file name is given as 0, /dev/null is used for the file.
> >> At line 60 of file set-obs.d.f (unit = 2, file = 'x=')
> >> Fortran runtime error: File 'agsm.mesa' does not exist
> >> FAILED
> >> /cygdrive/c/Programme/MESA/adipls/test
> >> TEST FAILED -- compare obs.txt to obs.test.txt
> >>
> >> Any idea, why that file cannot be opened? Was it opened for 'writing' only?
> >>
> >> Thank you for help,
> >> Nadine
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> >> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> >> endpoint security space. For insight on selecting the right partner to
> >> tackle endpoint security challenges, access the full report.
> >> http://p.sf.net/sfu/symantec-dev2dev
> >> _______________________________________________
> >> mesa-users mailing list
> >> mesa-users at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/mesa-users
> >
> >
> >
> >
> >------------------------------
> >
> >Message: 2
> >Date: Sun, 10 Mar 2013 18:38:44 +0000
> >From: Nadine Nettelmann <nadine.nettelmann at uni-rostock.de>
> >Subject: [mesa-users] MESA SDK installation problem
> >To: "mesa-users at lists.sourceforge.net"
> > <mesa-users at lists.sourceforge.net>
> >Message-ID:
> > <037F3141B9C79D42857DEF1C741F5E752D9C1504 at mbx3.uni-rostock.de>
> >Content-Type: text/plain; charset="us-ascii"
> >
> >Hi,
> >we are trying to install MESA both with and without the SDK. Without the sdk, all modules but nse and adipls could be installed properly.
> >However, with the SDK we run into apparently SDK relatied problems, please see below the report of our admin (Hart):
> >
> >Firstly, about the machine;
> >
> >[nadinen at umbriel a]$ uname -a
> >Linux umbriel.ucolick.org 2.6.32-279.22.1.el6.x86_64 #1 SMP Wed Feb 6 03:10:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> >
> >[nadinen at umbriel a]$ echo $PATH
> >/a/mesasdk/bin:/u/nadinen/bin:/a/gcc/bin:/usr/bin:/usr/sbin: /bin:/sbin:/opt/bin:/opt/share/bin:/usr/X11R6/bin
> >
> >[nadinen at umbriel a]$ pwd
> >/a
> >[nadinen at umbriel a]$ tar xfBpz mesasdk-x86_64-linux-20120809.tar.gz
> >[nadinen at umbriel a]$ export MESASDK_ROOT=/a/mesasdk
> >[nadinen at umbriel a]$ source $MESASDK_ROOT/bin/mesasdk_init.sh
> >
> >Following the instruction here:
> >
> >http://www.astro.wisc.edu/~townsend/static.php?ref=mesasdk #Installation
> >
> >I run:
> >
> >[nadinen at umbriel a]$ gfortran --version
> >
> >Where it hangs.
> >
> >I ran a stack trace against gfortran:
> >
> >[nadinen at umbriel a]$ which gfortran
> >/a/mesasdk/bin/gfortran
> >[nadinen at umbriel a]$ strace gfortran --version
> >
> >and I see:
> >
> >execve("/a/mesasdk/bin/gfortran.exec", ["/a/mesasdk/bin/gfortran.exec", "--version"], [/* 27 vars */]) = 0
> >brk(0) = 0x1070000
> >mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f87a72f9000
> >access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
> >open("/home/townsend/mesasdk/lib64/tls/x86_64/libm.so.6 ", O_RDONLY) = -1 ENOENT (No such file or directory)
> >stat("/home/townsend/mesasdk/lib64/tls/x86_64", 0x7fff3113d750) = -1 ENOENT (No such file or directory)
> >open("/home/townsend/mesasdk/lib64/tls/libm.so.6", O_RDONLY = -1 ENOENT (No such file or directory)
> >stat("/home/townsend/mesasdk/lib64/tls", 0x7fff3113d750) = -1 ENOENT (No such file or directory)
> >open("/home/townsend/mesasdk/lib64/x86_64/libm.so.6 ", O_RDONLY
> >
> >it goes on and on with calls to /home/townsend/mesasdk, which doesn't exist. Why is it making calls to /home/townsend? Any help would be appreciated.
> >
> >-Hart
> >
> >Many thanks for help,
> >Nadine
> >
> >
> >------------------------------
> >
> >Message: 3
> >Date: Sun, 10 Mar 2013 14:07:04 -0500
> >From: Richard Townsend <townsend at astro.wisc.edu>
> >Subject: Re: [mesa-users] MESA SDK installation problem
> >To: Nadine Nettelmann <nadine.nettelmann at uni-rostock.de>
> >Cc: "mesa-users at lists.sourceforge.net"
> > <mesa-users at lists.sourceforge.net>
> >Message-ID: <53C142ED-6F07-4B5E-84B3-7A457A6DDD70 at astro.wisc.edu>
> >Content-Type: text/plain; charset=us-ascii
> >
> >Hi Nadine --
> >
> >Thanks for the detailed report.
> >
> >On Mar 10, 2013, at 1:38 PM, Nadine Nettelmann wrote:
> >
> >> Hi,
> >> we are trying to install MESA both with and without the SDK. Without the sdk, all modules but nse and adipls could be installed properly.
> >> However, with the SDK we run into apparently SDK relatied problems, please see below the report of our admin (Hart):
> >>
> >> Firstly, about the machine;
> >>
> >> [nadinen at umbriel a]$ uname -a
> >> Linux umbriel.ucolick.org 2.6.32-279.22.1.el6.x86_64 #1 SMP Wed Feb 6 03:10:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> >>
> >> [nadinen at umbriel a]$ echo $PATH
> >> /a/mesasdk/bin:/u/nadinen/bin:/a/gcc/bin:/usr/bin:/usr/sbin: /bin:/sbin:/opt/bin:/opt/share/bin:/usr/X11R6/bin
> >>
> >> [nadinen at umbriel a]$ pwd
> >> /a
> >> [nadinen at umbriel a]$ tar xfBpz mesasdk-x86_64-linux-20120809.tar.gz
> >> [nadinen at umbriel a]$ export MESASDK_ROOT=/a/mesasdk
> >> [nadinen at umbriel a]$ source $MESASDK_ROOT/bin/mesasdk_init.sh
> >>
> >> Following the instruction here:
> >>
> >> http://www.astro.wisc.edu/~townsend/static.php?ref=mesasdk #Installation
> >>
> >> I run:
> >>
> >> [nadinen at umbriel a]$ gfortran --version
> >>
> >> Where it hangs.
> >>
> >> I ran a stack trace against gfortran:
> >>
> >> [nadinen at umbriel a]$ which gfortran
> >> /a/mesasdk/bin/gfortran
> >> [nadinen at umbriel a]$ strace gfortran --version
> >>
> >> and I see:
> >>
> >> execve("/a/mesasdk/bin/gfortran.exec", ["/a/mesasdk/bin/gfortran.exec", "--version"], [/* 27 vars */]) = 0
> >> brk(0) = 0x1070000
> >> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f87a72f9000
> >> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
> >> open("/home/townsend/mesasdk/lib64/tls/x86_64/libm.so.6 ", O_RDONLY) = -1 ENOENT (No such file or directory)
> >> stat("/home/townsend/mesasdk/lib64/tls/x86_64", 0x7fff3113d750) = -1 ENOENT (No such file or directory)
> >> open("/home/townsend/mesasdk/lib64/tls/libm.so.6", O_RDONLY = -1 ENOENT (No such file or directory)
> >> stat("/home/townsend/mesasdk/lib64/tls", 0x7fff3113d750) = -1 ENOENT (No such file or directory)
> >> open("/home/townsend/mesasdk/lib64/x86_64/libm.so.6 ", O_RDONLY
> >>
> >> it goes on and on with calls to /home/townsend/mesasdk, which doesn't exist. Why is it making calls to /home/townsend? Any help would be appreciated.
> >>
> >
> >It's trying to access this directory because that's where mesasdk was installed when I built the SDK. However, these references to /home/townsend/mesasdk shouldn't matter, because the SDK installs a wrapper script which overrides these library paths -- see $MESASDK_ROOT/bin/gcc.wrapper.
> >
> >In any case, the problem is fundamentally that the gfortran executable (gfortran.exec) can't find the standard math library (libm.so) installed on your system. To track this library down, can you send me the output of 'ls -l /lib64'
> >
> >Many thanks,
> >
> >Rich
> >
> >> -Hart
> >>
> >> Many thanks for help,
> >> Nadine
> >> ------------------------------------------------------------------------------
> >> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> >> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> >> endpoint security space. For insight on selecting the right partner to
> >> tackle endpoint security challenges, access the full report.
> >> http://p.sf.net/sfu/symantec-dev2dev
> >> _______________________________________________
> >> mesa-users mailing list
> >> mesa-users at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/mesa-users
> >
> >
> >
> >
> >------------------------------
> >
> >Message: 4
> >Date: Mon, 11 Mar 2013 16:45:48 +1100
> >From: Aaron Dotter <aaron.dotter at gmail.com>
> >Subject: [mesa-users] MESA sourceforge upgrade and new svn repository
> >To: mesa-users <mesa-users at lists.sourceforge.net>
> >Message-ID:
> > <CAN5--jP-2HN2nHMyEiqNGsxrycL3Q-tA8OaL53NcTP8P38RFNg at mail.gmail.com>
> >Content-Type: text/plain; charset="iso-8859-1"
> >
> >Hi mesa-users,
> >
> >The upgrade of MESA to the new sourceforge platform was completed
> >successfully over the weekend. *The only major change for most users is
> >that the svn repository has a new address.*
> >
> >The simplest way to keep up to date with MESA is to check out a new copy
> >from the new repository; it's as simple as that. New changes to the
> >codebase will then simply require an svn update. The new repository
> >address is up on the "getting started" page:
> >
> >http://mesa.sourceforge.net/getting_started.html#download
> >
> >If you maintain a working copy of MESA under version control for
> >development purposes, see the MESA FAQ for more info (http://goo.gl/FpsBA)
> >
> >If you have any problems or questions along the way, please send them to
> >mesa-users.
> >
> >Thanks for your patience!
> >
> >Aaron
> >on behalf of the MESA Council
> >-------------- next part --------------
> >An HTML attachment was scrubbed...
> >
> >------------------------------
> >
> >Message: 5
> >Date: Mon, 11 Mar 2013 10:26:57 -0700
> >From: Bill Paxton <paxton at kitp.ucsb.edu>
> >Subject: [mesa-users] mesa/star problem with ifort 12.0.4
> >To: "mesa-users at lists.sourceforge.net [mesa-users at lists.sourceforge"
> > <mesa-users at lists.sourceforge.net>
> >Message-ID: <443033D7-846C-4845-A04C-931E8BD55876 at kitp.ucsb.edu>
> >Content-Type: text/plain; charset=us-ascii
> >
> >Hi,
> >
> >Are you using ifort to compile mesa? If so, you might want to help track down
> >a problem that is breaking mesa/star when compiled with ifort 12.0.4 on a mac.
> >It is present in version 4836 -- many of the test suite cases run, but there
> >are several that segfault in the same location immediately at the start
> >of a run. The segfault is in these 5 lines in the set_xa routine in adjust_mass.
> >
> > do k=k_const_mass+1,nz
> > do j=1,species
> > s% xa(j,k) = xa_old(j,k)
> > end do
> > end do
> >
> >I printed out the sizes of the arrays and they are okay.
> >If I turn on bounds checking, the segfault doesn't happen.
> >If I leave bounds checking off, and change from -O2 to -O,
> >the segfault doesn't happen.
> >If I rewrite the nested loops as
> > forall (j=1:species,k=k_const_mass+1:nz) s% xa(j,k) = xa_old(j,k)
> >the segfault doesn't happen even with -O2.
> >I'm not willing to change the do's to forall's to paper over the problem!
> >In fact, I'm removing forall's since they making array temporaries
> >on the stack, and for very large arrays that can produce a segfault.
> >
> >
> >Does this happen when you run it? Does it happen in newer ifort's?
> >
> >
> >Thanks,
> >Bill
> >
> >
> >here's the routine with added debugging statements
> >
> > subroutine set_xa( &
> > s, nz, k_const_mass, species, xa_old, xaccrete, &
> > old_cell_xbdy, new_cell_xbdy, mmax, old_cell_mass, new_cell_mass, ierr)
> > ! set new values for s% xa(:,:)
> > type (star_info), pointer :: s
> > integer, intent(in) :: nz, k_const_mass, species
> > real(dp), intent(in) :: mmax
> > real(dp), intent(in), pointer :: xa_old(:, :), xaccrete(:)
> > real(dp), dimension(:), intent(in), pointer :: &
> > old_cell_xbdy, new_cell_xbdy, old_cell_mass, new_cell_mass ! (nz)
> > integer, intent(out) :: ierr
> > integer :: k, j, op_err
> > real(dp), parameter :: max_sum_abs = 10d0
> > real(dp), parameter :: xsum_tol = 1d-2
> > include 'formats'
> > ierr = 0
> > if (dbg_adjm) write(*,2) 'set_xa: k_const_mass', k_const_mass
> > if (k_const_mass < nz) then
> > ! for k >= k_const_mass have m_new(k) = m_old(k),
> > ! so no change in xa_new(:,k) for k > k_const_mass
> > write(*,3) 'set xa', k_const_mass, nz
> > write(*,2) 'size(s% xa, dim=1)', size(s% xa, dim=1)
> > write(*,2) 'size(xa_old, dim=1)', size(xa_old, dim=1)
> > write(*,2) 'species', species
> > write(*,2) 'size(s% xa, dim=2)', size(s% xa, dim=2)
> > write(*,2) 'size(xa_old, dim=2)', size(xa_old, dim=2)
> > write(*,2) 'nz', nz
> > write(*,1) 's% xa(1,k_const_mass+1)', s% xa(1,k_const_mass+1)
> > write(*,1) 's% xa(species,nz)', s% xa(species,nz)
> > write(*,1) 'xa_old(1,k_const_mass+1)', xa_old(1,k_const_mass+1)
> > write(*,1) 'xa_old(species,nz)', xa_old(species,nz)
> > forall (j=1:species,k=k_const_mass+1:nz) s% xa(j,k) = xa_old(j,k)
> > write(*,*) 'done forall'
> > do k=k_const_mass+1,nz
> > do j=1,species
> > s% xa(j,k) = xa_old(j,k)
> > end do
> > end do
> > write(*,*) 'done'
> > end if
> >!$OMP PARALLEL DO PRIVATE(k, op_err)
> > do k = 1, k_const_mass
> > op_err = 0
> > call set1_xa(s, k, nz, species, xa_old, xaccrete, &
> > old_cell_xbdy, new_cell_xbdy, mmax, old_cell_mass, new_cell_mass, op_err)
> > if (op_err /= 0) ierr = op_err
> > end do
> >!$OMP END PARALLEL DO
> >
> > end subroutine set_xa
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >------------------------------
> >
> >Message: 6
> >Date: Wed, 13 Mar 2013 10:40:00 +0000
> >From: Rob.Farmer <Rob.Farmer at open.ac.uk>
> >Subject: Re: [mesa-users] mesa/star problem with ifort 12.0.4
> >To: Bill Paxton <paxton at kitp.ucsb.edu>,
> > "mesa-users at lists.sourceforge.net [mesa-users at lists.sourceforge"
> > <mesa-users at lists.sourceforge.net>
> >Message-ID:
> > <9932A16F9CE9264FAC3F2E0E008E122107B7E56B56 at KIELDERCMS1.open.ac.uk>
> >Content-Type: text/plain; charset="us-ascii"
> >
> >Hi,
> >
> >This is the problem i reported a few weeks ago and that occurs with ifort 13 on fedora 17 64bit.
> >
> >Though for me this only occurred when running MESA (v4798) itself (it passed the test suite) outside of the main MESA directory
> >
> >I'll give the newer version ago when i get a chance with the newer ifort
> >
> >Rob
> >________________________________________
> >From: Bill Paxton [paxton at kitp.ucsb.edu]
> >Sent: 11 March 2013 17:26
> >To: mesa-users at lists.sourceforge.net [mesa-users at lists.sourceforge
> >Subject: [mesa-users] mesa/star problem with ifort 12.0.4
> >
> >Hi,
> >
> >Are you using ifort to compile mesa? If so, you might want to help track down
> >a problem that is breaking mesa/star when compiled with ifort 12.0.4 on a mac.
> >It is present in version 4836 -- many of the test suite cases run, but there
> >are several that segfault in the same location immediately at the start
> >of a run. The segfault is in these 5 lines in the set_xa routine in adjust_mass.
> >
> > do k=k_const_mass+1,nz
> > do j=1,species
> > s% xa(j,k) = xa_old(j,k)
> > end do
> > end do
> >
> >I printed out the sizes of the arrays and they are okay.
> >If I turn on bounds checking, the segfault doesn't happen.
> >If I leave bounds checking off, and change from -O2 to -O,
> >the segfault doesn't happen.
> >If I rewrite the nested loops as
> > forall (j=1:species,k=k_const_mass+1:nz) s% xa(j,k) = xa_old(j,k)
> >the segfault doesn't happen even with -O2.
> >I'm not willing to change the do's to forall's to paper over the problem!
> >In fact, I'm removing forall's since they making array temporaries
> >on the stack, and for very large arrays that can produce a segfault.
> >
> >
> >Does this happen when you run it? Does it happen in newer ifort's?
> >
> >
> >Thanks,
> >Bill
> >
> >
> >here's the routine with added debugging statements
> >
> > subroutine set_xa( &
> > s, nz, k_const_mass, species, xa_old, xaccrete, &
> > old_cell_xbdy, new_cell_xbdy, mmax, old_cell_mass, new_cell_mass, ierr)
> > ! set new values for s% xa(:,:)
> > type (star_info), pointer :: s
> > integer, intent(in) :: nz, k_const_mass, species
> > real(dp), intent(in) :: mmax
> > real(dp), intent(in), pointer :: xa_old(:, :), xaccrete(:)
> > real(dp), dimension(:), intent(in), pointer :: &
> > old_cell_xbdy, new_cell_xbdy, old_cell_mass, new_cell_mass ! (nz)
> > integer, intent(out) :: ierr
> > integer :: k, j, op_err
> > real(dp), parameter :: max_sum_abs = 10d0
> > real(dp), parameter :: xsum_tol = 1d-2
> > include 'formats'
> > ierr = 0
> > if (dbg_adjm) write(*,2) 'set_xa: k_const_mass', k_const_mass
> > if (k_const_mass < nz) then
> > ! for k >= k_const_mass have m_new(k) = m_old(k),
> > ! so no change in xa_new(:,k) for k > k_const_mass
> > write(*,3) 'set xa', k_const_mass, nz
> > write(*,2) 'size(s% xa, dim=1)', size(s% xa, dim=1)
> > write(*,2) 'size(xa_old, dim=1)', size(xa_old, dim=1)
> > write(*,2) 'species', species
> > write(*,2) 'size(s% xa, dim=2)', size(s% xa, dim=2)
> > write(*,2) 'size(xa_old, dim=2)', size(xa_old, dim=2)
> > write(*,2) 'nz', nz
> > write(*,1) 's% xa(1,k_const_mass+1)', s% xa(1,k_const_mass+1)
> > write(*,1) 's% xa(species,nz)', s% xa(species,nz)
> > write(*,1) 'xa_old(1,k_const_mass+1)', xa_old(1,k_const_mass+1)
> > write(*,1) 'xa_old(species,nz)', xa_old(species,nz)
> > forall (j=1:species,k=k_const_mass+1:nz) s% xa(j,k) = xa_old(j,k)
> > write(*,*) 'done forall'
> > do k=k_const_mass+1,nz
> > do j=1,species
> > s% xa(j,k) = xa_old(j,k)
> > end do
> > end do
> > write(*,*) 'done'
> > end if
> >!$OMP PARALLEL DO PRIVATE(k, op_err)
> > do k = 1, k_const_mass
> > op_err = 0
> > call set1_xa(s, k, nz, species, xa_old, xaccrete, &
> > old_cell_xbdy, new_cell_xbdy, mmax, old_cell_mass, new_cell_mass, op_err)
> > if (op_err /= 0) ierr = op_err
> > end do
> >!$OMP END PARALLEL DO
> >
> > end subroutine set_xa
> >
> >
> >
> >
> >
> >
> >
> >------------------------------------------------------------------------------
> >Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> >Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> >endpoint security space. For insight on selecting the right partner to
> >tackle endpoint security challenges, access the full report.
> >http://p.sf.net/sfu/symantec-dev2dev
> >_______________________________________________
> >mesa-users mailing list
> >mesa-users at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/mesa-users
> >
> >--
> >The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).
> >
> >
> >
> >
> >------------------------------
> >
> >------------------------------------------------------------------------------
> >Everyone hates slow websites. So do we.
> >Make your web apps faster with AppDynamics
> >Download AppDynamics Lite for free today:
> >http://p.sf.net/sfu/appdyn_d2d_mar
> >
> >------------------------------
> >
> >_______________________________________________
> >mesa-users mailing list
> >mesa-users at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/mesa-users
> >
> >
> >End of mesa-users Digest, Vol 43, Issue 13
> >******************************************
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar_______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users
More information about the Mesa-users
mailing list