[Mesa-users] Failed with STOP op_load

Kuldeep Verma kuldeepv89 at gmail.com
Thu Feb 8 10:04:00 EST 2018


Hi Rich,

Thank you for your email. Here you go...

[kuldeep at s81n11 mixing_process]$ ldd ./star
    linux-vdso.so.1 =>  (0x00007f506e4cf000)
    libhdf5_fortran.so.10 =>
/home/kuldeep/mesasdk/lib/libhdf5_fortran.so.10 (0x00007f506e27f000)
    libhdf5.so.10 => /home/kuldeep/mesasdk/lib/libhdf5.so.10
(0x00007f506dd3e000)
    libz.so.1 => /usr/lib64/libz.so.1 (0x00007f506db18000)
    libpgplot.so => /home/kuldeep/mesasdk/lib/libpgplot.so
(0x00007f506d879000)
    libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f506d53a000)
    libgfortran.so.3 => /home/kuldeep/mesasdk/lib64/libgfortran.so.3
(0x00007f506d20c000)
    libm.so.6 => /usr/lib64/libm.so.6 (0x00007f506cf0a000)
    libgomp.so.1 => /home/kuldeep/mesasdk/lib64/libgomp.so.1
(0x00007f506cce6000)
    libgcc_s.so.1 => /home/kuldeep/mesasdk/lib64/libgcc_s.so.1
(0x00007f506cacf000)
    libquadmath.so.0 => /home/kuldeep/mesasdk/lib64/libquadmath.so.0
(0x00007f506c890000)
    libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007f506c673000)
    libc.so.6 => /usr/lib64/libc.so.6 (0x00007f506c2b1000)
    librt.so.1 => /usr/lib64/librt.so.1 (0x00007f506c0a9000)
    libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f506bea4000)
    libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f506bc82000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f506e4d1000)
    libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f506ba7d000)

Let me just add briefly one issue that I had during the installation
recently (which may or may not be related). I could not install mesa-r10108
with the mesasdk released after August 2017 (the latest mesasdk that worked
for me was released on 2nd August 2017). I posted the details of the issue
on the forum last week.

Best wishes,
Kuldeep

On Thu, Feb 8, 2018 at 3:43 PM, RICHARD H D TOWNSEND <
townsend at astro.wisc.edu> wrote:

> Hi Kuldeep —
>
> This is indeed a strange set of errors. Can I ask that you change into
> your working directory, and post the output from the command
>
> ldd ./star
>
> Many thanks,
>
> Rich
>
> On Feb 8, 2018, at 7:52 AM, Kuldeep Verma via Mesa-users <
> mesa-users at lists.mesastar.org> wrote:
>
> Hi Rob,
>
> Many thanks for the suggestion. I downloaded the fresh tar file, and ended
> up with the following error message:
>
>                                          version_number       10108
>  read inlist_with_levitation
> load saved model start_m1.3.mod
>
>  loading OP mono data...
> At line 179 of file ../private/op_load.f (unit = 1, file =
> 'OP4STARS_1.3/mono/m01.mesh')
> Fortran runtime error: Unformatted file structure has been corrupted
>
>
> Best wishes,
> Kuldeep
>
> On Thu, Feb 8, 2018 at 1:42 PM, Rob Farmer <r.j.farmer at uva.nl> wrote:
>
>> Hi
>> >Just to inform everyone, the read statement fails with an iostat value
>> of 5016 (LIBERROR_SHORT_RECORD).
>>
>> Sounds like the file got corrupted, try re downloading it
>>
>> Rob
>>
>> On 8 February 2018 at 13:23, Kuldeep Verma via Mesa-users <
>> mesa-users at lists.mesastar.org> wrote:
>>
>>> Hi Frank,
>>>
>>> Thank you so much for pointing that out. Obviously I needed some rest.
>>> Just to inform everyone, the read statement fails with an iostat value of
>>> 5016 (LIBERROR_SHORT_RECORD). I have been trying various things without any
>>> success yet. Any suggestion on what to try would be more than welcome.
>>>
>>> >>>you may also want to try using the full pathname for
>>> op_mono_data_path and op_mono_data_path instead of what appears to be a
>>> relative pathname.
>>> I tried that. OPEN statement is fine (fails on the READ statement).
>>>
>>> Best wishes,
>>> Kuldeep
>>>
>>> On Wed, Feb 7, 2018 at 7:40 PM, Francis Timmes <fxt44 at mac.com> wrote:
>>>
>>>> > I added "write(*,*) ios" just before stop statement; cd
>>>> mesa-r10108/kap/; ./clean; ./mk; ./export
>>>>
>>>> yes.
>>>>
>>>> assuming you are running the test case from
>>>> star/test_suite/radiative_levitation
>>>> be sure to do a ./clean ; ./mk in the test directory to pick up the
>>>> changes made
>>>> to kap/private/op_load.f. as a check, i added such write statements to
>>>> kap/private/op_load.f
>>>> and the executable dutifully reported my writes of the  ios variable:
>>>>
>>>>  initial setting ios           0
>>>>  ios after open           0
>>>>  reading OP cache file /Users/fxt/mesa_work/OP4STARS_
>>>> 1.3/mono/op_mono_cache.bin
>>>>  done reading OP cache file
>>>>  ios after close           0
>>>>
>>>> you may also want to try using the full pathname for op_mono_data_path
>>>> and
>>>> op_mono_data_path instead of what appears to be a relative pathname.
>>>>
>>>> fxt
>>>>
>>>>
>>>>
>>>>
>>>> > On Feb 7, 2018, at 9:21 AM, Kuldeep Verma via Mesa-users <
>>>> mesa-users at lists.mesastar.org> wrote:
>>>> >
>>>> > Dear All,
>>>> >
>>>> > I recently installed mesa-r10108 on a Linux cluster successfully. I
>>>> ran few test_suite cases without any problem (specifically,
>>>> example_solar_model and example_astero). The run failed for the test_suite
>>>> case radiative_levitation with the following error message:
>>>> >
>>>> >                                          version_number       10108
>>>> >  read inlist_radiative_levitation
>>>> >  extras_controls set pointer to set_op_mono_factors
>>>> >  eosDT_use_linear_interp_for_X T
>>>> > load saved model sdb.mod
>>>> >
>>>> >  reading OP cache file OP4STARS_1.3/mono/op_mono_cache.bin
>>>> >  done reading OP cache file
>>>> >  failed in reading cache file
>>>> >
>>>> > I have attached the inlist with the email (you need to download the
>>>> op mono opacity from https://sourceforge.net/projects/mesa/files/ if
>>>> you want to run it). The following are the only two lines that I changed in
>>>> the inlist:
>>>> >          op_mono_data_path = 'OP4STARS_1.3/mono'
>>>> >          op_mono_data_cache_filename = 'OP4STARS_1.3/mono/op_mono_cac
>>>> he.bin'
>>>> >
>>>> > Let me add that I can run the radiative_levitation test case with
>>>> mesa-r10108 on my PC. It fails only on the cluster. The following is the
>>>> piece of code from mesa-r10108/kap/private/op_load.f where it fails
>>>> >
>>>> >       ios = 0
>>>> >       open(1,file=trim(cache_filename),action='read',
>>>> >      >         status='old',iostat=ios,form='unformatted')
>>>> >       if (ios == 0) then
>>>> >          write(*,*) 'reading OP cache file ' // trim(cache_filename)
>>>> >          read(1,iostat=ios) ntotv,dv,dv1,umesh,
>>>> >      >      ite1,ite2,ite3,jn1,jn2,jne3,um
>>>> in,umax,ntotp,nc,nf,int,epatom,oplnck, ne1p,
>>>> >      >      ne2p,fionp,np,kp1,kp2,kp3,npp,mx,yy1,yy2,nx,yx
>>>> >          write(*,*) 'done reading OP cache file'
>>>> >          close(1)
>>>> >          if (ios == 0) then
>>>> >             have_loaded_op = .true.
>>>> >             CALL IMESH(UMESH,NTOTV)
>>>> >             goto 1001
>>>> >          end if
>>>> >          write(*,*) 'failed in reading cache file'
>>>> >          stop 'op_load'
>>>> >       end if
>>>> >
>>>> > I tried printing the variable ios without any success (I added
>>>> "write(*,*) ios" just before stop statement; cd mesa-r10108/kap/; ./clean;
>>>> ./mk; ./export). Can someone help me printout this variable, please? Any
>>>> insight on what may be going on would be highly appreciated.
>>>> >
>>>> > Best wishes,
>>>> > Kuldeep
>>>> >
>>>> >
>>>> > <inlist_radiative_levitation>_______________________________
>>>> ________________
>>>> > mesa-users at lists.mesastar.org
>>>> > https://lists.mesastar.org/mailman/listinfo/mesa-users
>>>> >
>>>>
>>>>
>>>
>>
> _______________________________________________
> 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/20180208/e8401010/attachment.html>


More information about the Mesa-users mailing list