[mesa-users] mesa-users Digest, Vol 43, Issue 13
Bill Paxton
paxton at kitp.ucsb.edu
Mon Mar 18 11:34:40 EDT 2013
Hi,
The code doesn't create a filename from the initial_z (perhaps it should!).
So you need to set the 'zams_filename' -- see star/private/controls.defaults.
-Bill
On Mar 18, 2013, at 5:16 AM, WU T. 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
> < br>
>
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130318/0810d5be/attachment.html>
More information about the Mesa-users
mailing list