search

usnistgov / REFPROP-issues

A repository solely used for reporting issues with NIST REFPROP
26 stars 13 forks source link

Runtime error (access violation) when calling REFPROP's SETUP #670

Open PeterCame448 opened 2 months ago

PeterCame448 commented 2 months ago

If you have an issue to report, please continue and fill out the applicable sections below. The details provided will help to resolve this issue as quickly as possible.

Prerequisites

NOTE: Be aware that all issues are publicly accessible and viewable. Thus please do not post any code or other content that is protected intellectual property or under copyright.

Before posting an issue, please:

You can also use markdown to format your issue: GitHub guide on Markdown. If you have code snippets, please use a code block to ensure that the formatting remains legible in the web interface. For instance, surround your code in triple backticks:

print('Hello world!')

Description

  1. I have previously developed a code in Microsoft Visual FORTRAN which successfully called and used REFPROP routines (call this 'Code A').

  2. I am currently developing a new code - 'Code B' - (also in Microcrosoft Visual FORTRAN), basing it on an earlier code ('Code C') which did not call REFPROP. The newly developing code (Code B) does call REFPROP routines.

  3. Both Codes A and B start by calling SETPATH and then SETUP and then INFO, as is customary. Code A does all this successfully.

  4. However, Code B incurs a runtime error during the execution of its call to SETUP. The wording of the error is: 'Unhandled exception; access violation'. When the run errors, a line in SETUP is indicated - about line 220 of SETUP.FOR (but this can vary). There is nothing special about this line of code.

  5. As far as I can tell, the FORTRAN leading up to the call to SETUP is effectively the same for both Code A and Code B; I've tried to be particularly careful about declarations, especially of the 6 arguments that SETUP requires. But Code A runs and Code B fails.

  6. After several days of working the problem, I think I really need some expert help, please! I hope the information provided is sufficient.

(I am using REFPROP 10).

PeterCame448 commented 2 months ago

Can anyone help with this Issue, please?

bigoper commented 2 months ago

Hi @PeterCame448

ianhbell commented 2 months ago

The core problem is that REFPROP is neither thread-safe nor process-safe.

A) Reads (calls to SETUP) have to be protected with a lock or similar threading primitive because file reads cannot be done concurrently B) Copies of the FLUIDS and MIXTURE folders should be made for each process

PeterCame448 commented 2 months ago

To be clear about my ability: I’m an engineer with a fair bit of FORTRAN experience but probably have got by without having to understand some of the finer points of coding.

So, in A), the terms ‘thread-safe’ and ‘process-safe’ don’t mean much to me. Nor do I understand ‘protected with a lock’. Please could you explain. Thanks.

For B): Both programs access /FLUIDS and /MIXTURES by using SETPATH to direct them to C:/Program Files (x86)/REFPROP.

ianhbell commented 2 months ago

You need to make another copy of the REFPROP stuff. Program A needs to use copy A and program B needs to use copy B.

Somehow you have to synchronize your programs so that ALL the SETUP happens serially and there are no collisions between the programs. This is a HARD problem. I take it you mean that you have separate executables built from the FORTRAN sources and each is run as its own process? If so, it should be sufficient to just use the contents from the separate copies without additional safeguards.

PeterCame448 commented 2 months ago

Thanks again.

I should have mentioned that the two programs A and B are entirely separate, do entirely different calculations, and are never run at the same time, or even with runs overlapping. Different and separate executables are built on separate compilation of the two codes.

The only things they have in common are that they both use REFPROP and both start by calling the REFPROP subroutines SETPATH, SETUP, and INFO.

At runtime, both programs execute the call to SETPATH ok but Program A fails when SETUP is called whereas Program B calls SETUP successfully and completes the rest of its calculations

Does this make a difference to your diagnosis?

ianhbell commented 2 months ago

Aside: it is better if you respond in the web client, I stripped out the email cruft.

If you have separate programs that operate entirely independently, that should mean that you have a much easier use case. The program B must have a bug of some sort. So please show what you tried to do and what error(s) you get.

PeterCame448 commented 2 months ago

Thanks. [The Ok code is called Code A and the failing code is called Code B. I may have reversed this naming in an earlier entry - my apologies].

Here are three screenshots:

  1. Code A: the code that calls the REFPROP subs SETUP and INFO
  2. Code B: the code that calls the REFPROP subs SETPATH, SETUP, and INFO
  3. the runtime failure that occurs in Code B when SETUP is called

Hope this helps. Let me know if anything else would be of help.

PeterCame448 commented 2 months ago

Sorry - did not intend to close this topic

PeterCame448 commented 2 months ago

Promised screenshots CodeA_sub_main_prog CodeB_sub_Refprop_setup runtime_failure_in_sub_setup CodeA_sub_main_prog CodeB_sub_Refprop_setup runtime_failure_in_sub_setup

ianhbell commented 2 months ago

Is that variable hWEB allocated to the right size?

PeterCame448 commented 2 months ago

hWEB is a REFPROP variable occurring twice in SETUP.FOR and once in REFPROP.FOR. I'd assumed that, as it is a REFPROP variable, it was OK and that the code stopping on the line: hWEB = ' ' wasn't caused by the variable itself. By the way, I followed your advice and re-loaded the REFPROP.FOR files from a newly made directory, local to the project, into which I had newly copied the files from C:/Program Files (x86)/REFPROP. The runtime error persisted unfortunately.

ianhbell commented 2 months ago

It seems like a memory corruption happened somewhere else before you got to this point. Because I agree that initializing the string to spaces should not cause a memory failure. Can you make a minimal example that reproduces this error?

PeterCame448 commented 2 months ago

Thanks again. I think you may be right about the memory corruption. I have got around the problem by a circuitous route:

From: Ian Bell @.> Sent: Tuesday, July 16, 2024 1:23 PM To: usnistgov/REFPROP-issues @.> Cc: Peter Came @.>; State change @.> Subject: Re: [usnistgov/REFPROP-issues] Runtime error (access violation) when calling REFPROP's SETUP (Issue #670)

It seems like a memory corruption happened somewhere else before you got to this point. Because I agree that initializing the string to spaces should not cause a memory failure. Can you make a minimal example that reproduces this error?

— Reply to this email directly, view it on GitHubhttps://github.com/usnistgov/REFPROP-issues/issues/670#issuecomment-2230755175, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BJZBVC2PNAMTVOFJYIZEV7DZMUGB7AVCNFSM6AAAAABKVPBAPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZQG42TKMJXGU. You are receiving this because you modified the open/close state.Message ID: @.***>

PeterCame448 commented 2 months ago

Thanks again. I think you may be right about the memory corruption. I have got around the problem by a circuitous route: • Rebuilding the FORTRAN project for the non-working code, code B, didn’t help, so …. • I gradually added the FORTRAN files of Code B to the FORTRAN Project of the working program, Code A • Then omitted the FORTRAN files of Code A • The ‘crossbreed’ code ran OK without the runtime error • So I’m able to continue developing Code B … but • I’m no wiser on what caused the error, and there is a messy file-naming issue in the crossbreed code – which I may find a solution to …

ianhbell commented 2 months ago

To truly get to the bottom of it you would need valgrind or similar tool. Just be glad you found it.