Opened 5 years ago

Last modified 5 years ago

#5448 reopened defect

OMEdit fails to open model, previously Totally Saved

Reported by: filip.jezek@… Owned by: adeas31
Priority: normal Milestone: 2.0.0
Component: Documentation Version: v1.14.0-dev-nightly
Keywords: Cc:

Description

Open model with dependencies on some libraries, Save Total, Open the saved file -> error: Unable to load the file/library.

"Only single non-structured entity is allowed to be stored in the file."

This kinda breaks the idea of Save Total, isnt it?

Attachments (4)

Smith_patSpec.mo (27.2 KB) - added by filip.jezek@… 5 years ago.
The file, saved by Save Total, error during the load.
TestPackage.mo (161 bytes) - added by Arinomo <trista.arinomo@…> 5 years ago.
Source Package
Model1.mo (221 bytes) - added by Arinomo <trista.arinomo@…> 5 years ago.
Initial Model
Model1Total.mo (314 bytes) - added by Arinomo <trista.arinomo@…> 5 years ago.
Save Total Model

Download all attachments as: .zip

Change History (23)

Changed 5 years ago by filip.jezek@…

The file, saved by Save Total, error during the load.

comment:1 Changed 5 years ago by casella

@filip, Could you also add the source files that were used to produced the save total'd model? This would allow to actually reproduce the issue

comment:2 Changed 5 years ago by filip.jezek@…

@casella Hi Francesco! Sure, here it is https://gist.github.com/filip-jezek/5404c3dc3687e31ae932e7bbd479f680

The Model2 contains the Model1. Model2 is TotalSaved into Model2Total. The Model2Total could not be opened.

comment:3 Changed 5 years ago by casella

  • Milestone changed from Future to 1.14.0
  • Owner changed from somebody to adeas31
  • Status changed from new to assigned

@adeas31, can you please take care of this or reassign it to somebody else who could? I'm not sure if this is an OMEdit issue or and interactive environment issue.

Thanks!

comment:4 Changed 5 years ago by sjoelund.se

Yes, saveTotal is not intended to use in OMEdit but rather in mos-scripting. OMEdit only accepts valid Modelica files whereas omc also accepts file with multiple classes on the top-level.

comment:5 Changed 5 years ago by casella

Ah, ok. I was also puzzled as Filip by the fact that OMEdit won't load Save Total files.

As usual, this is fine, as long as it is documented :)

See PR #109, @adeas31 can you please check, merge, and then close the ticket?

Thanks!

comment:6 Changed 5 years ago by adeas31

  • Component changed from *unknown* to Documentation
  • Resolution set to fixed
  • Status changed from assigned to closed

Changed 5 years ago by Arinomo <trista.arinomo@…>

Source Package

Changed 5 years ago by Arinomo <trista.arinomo@…>

Initial Model

Changed 5 years ago by Arinomo <trista.arinomo@…>

Save Total Model

comment:7 Changed 5 years ago by Arinomo <trista.arinomo@…>

  • Milestone changed from 1.14.0 to 2.0.0
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from v1.13.2 to v1.14.0-dev-nightly

This error happened to me on 1.14.0-dev-26584-gae23951b15.

comment:8 Changed 5 years ago by Arinomo <trista.arinomo@…>

So does it means, i can't open a model from save total from OMEdit(GUI)?

comment:9 Changed 5 years ago by Arinomo <trista.arinomo@…>

  • Resolution set to fixed
  • Status changed from reopened to closed

DidnT read the whole comments. Sorry

comment:10 Changed 5 years ago by casella

  • Resolution fixed deleted
  • Status changed from closed to reopened

I just added the documentation of saveFileTotal() to the NF PR 314 and to the old FE PR 315. Now that's in the documentation, there's no excuse for function abuse :)

@adeas31, can you please merge the PR's and re-close the ticket? Thanks!

comment:11 Changed 5 years ago by casella

In fact, it would be even better if OMEdit also caught the

Only single non-structured entity is allowed to be stored in the file.

message and printed out something like

Only single non-structured entity is allowed to be stored in the file.
If the file was generated by the API function saveTotalModel(), you can only load it with the API function loadFile() in a script or in the interactive environment, not in OMEdit

comment:12 follow-ups: Changed 5 years ago by anonymous

It is a bit strange that we can save through the GUI a file that we cannot read back through the GUI itself.

If the saved total is not a "valid modelica file" (comment 4) maybe it would have a different extension (say mot)?
In that case opening a "mot" file could be done using the code currently used for loadFile() in a script.
As far as I can tell this should be straightforward to implement given the existing loadFile() code.

The only drawback is that the "mot" would be an internal OM standard, not a Modelica standard format. But it is already like this, isn't it?

comment:13 in reply to: ↑ 12 Changed 5 years ago by casella

Replying to anonymous:

It is a bit strange that we can save through the GUI a file that we cannot read back through the GUI itself.

Indeed.

If the saved total is not a "valid modelica file" (comment 4) maybe it would have a different extension (say mot)?

That's a good idea.

In that case opening a "mot" file could be done using the code currently used for loadFile() in a script.

See my comment in PR 314

As far as I can tell this should be straightforward to implement given the existing loadFile() code.

The only drawback is that the "mot" would be an internal OM standard, not a Modelica standard format. But it is already like this, isn't it?

Indeed.

comment:14 in reply to: ↑ 12 Changed 5 years ago by ceraolo

In that case opening a "mot" file could be done using the code currently used for loadFile() in a script.

Not sure that this was clear enough.
I meant that using the same code of loadFile() in script should be easy to implement a GUI loading routine for "mot". This way, I think, the existing command open Model/Library Files() could be used to read such "mot" files.

comment:15 follow-up: Changed 5 years ago by Filip Ježek

Well, as I see, the problem is not in the improper usage of saveTotal, but in OM not importing a valid modelica file. Consider file test.mo:

model A
Boolean a = true;
end A;

model B
Boolean b = false;
end B;

that is, two models without encapsulated package. Dymola loads fine, OM raises an error and fails to open it. I was unable (please point me out otherwise) a clause in Modelica specification which disallows this.

The motivation is opening a number of supporting libraries within one file, which is simply generated (from both OM and other tools, such as Dymola). The workaround is writing a mos doing this, but still: OM is unable to open a valid .MO.

comment:16 in reply to: ↑ 15 Changed 5 years ago by casella

Replying to Filip Ježek:

Well, as I see, the problem is not in the improper usage of saveTotal, but in OM not importing a valid modelica file. Consider file test.mo:

model A
Boolean a = true;
end A;

model B
Boolean b = false;
end B;

that is, two models without encapsulated package. Dymola loads fine, OM raises an error and fails to open it. I was unable (please point me out otherwise) a clause in Modelica specification which disallows this.

See Section 13.2.: "package/classes are mapped into directories or files" (i.e., one directory or one file for each package or class, as I understand it).

See also Section 13.2.2.2:

  • When mapping a package or class-hierarchy to a file [e.g. the file A.mo ], that file shall only define a single class [ A ] with a name matching the name of the nonstructured entity.
  • A ".mo" file defining more than one class cannot be part of the mapping to file-structure and it is an error if it is loaded from the MODELICAPATH

comment:17 Changed 5 years ago by Filip Ježek

Ok, thanks for pointing me, i clearly overlooked that. That solves the issue then.
F/

comment:18 Changed 5 years ago by sjoelund.se

Well. It might be that OMEdit should ask the user if the file should be opened (read-only) anyway. That should not interfere with its ability to save the file again...

comment:19 Changed 5 years ago by casella

We are trying to adhere strictly to the specification. From this point of view, I guess OMC should not accept a .mo file which is invalid according to it.

I am personally in favour of the .mot file option.

Note: See TracTickets for help on using tickets.