Value of StringParameter not saved in Pro-II

[jasper]

In this case the easiest way to debug is to make sure you are running the Debug version of the DLL (regsvr32 for the Debug DLL), then start ProII, then from Visual Studio, choose Attach to Process from the Debug menu. Then select the ProII process - make sure to enable Native Debugging.

[SLiebschner]

The problems of the parameter in question were due to a space in the parameter creation. E.i. the diff of the fix is:

Code: Select all

- par = RealParameterObject::CreateParameter(L"porosity ", L"[-]", 0, NaN, NaN, dimensionality, &valStatus, CAPE_INPUT);
+ par = RealParameterObject::CreateParameter(L"porosity", L"[-]", 0, NaN, NaN, dimensionality, &valStatus, CAPE_INPUT);


For the record: This caused problems only in Pro-II, but not DWSIM.

Thus there is only one problem remaining: If I saved a parameter's value and want to change it there is no problem. However, if I want to delete the value, that's not possible. This means, deleting it in Pro-II, closing the window and opening it again, the former value is still there. I had contact with the Pro-II support about that problem and they said the following:

There is a PRO/II CAPE-OPEN limitation for missing real values. Pro/II uses RMISS (-1.5000000000000000e+35) for missing values of real parameters. But there is no corresponding CAPE-OPEN value for that missing value.
Thus, if a value is specified and saved, the value is saved in Pro/II. If this value is changed afterwards, there is no problem. But if the value is deleted, it is missing (RMISS in PRO/II) and RMISS cannot be handed over to the CAPE-OPEN unit. Thus the problem.

If you have any ideas how to deal with that problem, I am very grateful. However, a solution is not crucial and I can live with the current state.

[jasper]

The missing value for a real number in CAPE-OPEN is IEEE NaN. This is specified in the M&T guidelines.

This complies with e.g. _isnan(), std::isnan() and std::numeric<double>::quiet_nan()

So NaN is the equivalent of RMISS.

[SLiebschner]

Ok, what does that come down to? As I read your answer, it should work. But it doesn't.
Is there anything I can do?

[jasper]

I had contact with the Pro-II support about that problem and they said the following:

There is a PRO/II CAPE-OPEN limitation for missing real values. Pro/II uses RMISS (-1.5000000000000000e+35) for missing values of real parameters. But there is no corresponding CAPE-OPEN value for that missing value.
Thus, if a value is specified and saved, the value is saved in Pro/II. If this value is changed afterwards, there is no problem. But if the value is deleted, it is missing (RMISS in PRO/II) and RMISS cannot be handed over to the CAPE-OPEN unit. Thus the problem.

It was a response to this quote. Perhaps you can reply to them along the same lines? See what the outcome is?

[jasper]

A possible solution to your problem would be to not allow missing values on your parameter. Make sure that all parameters have a default and initial value, and if the simulator tries to set a value that is missing or out of bounds, raise an error. Implement Validate on your parameter accordingly.

[SLiebschner]

That is not what I want. If a parameter is not specified, I want to use defaults which are set elsewhere.
Currently, those defaults are used, if the parameter is nan.

I forwarded your comment

The missing value for a real number in CAPE-OPEN is IEEE NaN. This is specified in the M&T guidelines.

This complies with e.g. _isnan(), std::isnan() and std::numeric<double>::quiet_nan()

So NaN is the equivalent of RMISS.

The answer is that it requires modifications of Pro/II's CAPE-OPEN interface and might be part of a future release.

Anyway, I can live with the present situation. Thanks for your help!

[jasper]

Another potential solution is to have a GUI that allows the user to determine which are the specifications, and adapt the parameter collection accordingly. Nearly all COUSCOUS unit operations work like that.

[SLiebschner]

What is then the difference to the status quo? It is already a GUI with fields to be filled in for each parameter.

[jasper]

Instead of having e.g. length = not specified, volume is specified, or volume is specified and length is not specified, you would ask the user in the dialog: specify length or volume? In one case length becomes an input and volume an output, in the other case vice versa. In no case are input parameter unspecified in this scenario.