[Mesa-users] Failed with STOP op_load

[Kuldeep Verma]

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
>>> >
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20180208/e5e2ee5b/attachment.html>