Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#4583 closed defect (fixed)

files for CombiTimeTable not found anymore

Reported by: massimo ceraolo Owned by: Adeel Asghar
Priority: high Milestone: 1.13.0
Component: OMEdit Version:
Keywords: Cc:

Description (last modified by massimo ceraolo)

I have models which use CombiTimeTables with data from file.
In the past I put the relevant txt files in the directory indicated in OMEdit as Working directory.
Now, however, with the recent changes which store files in subfolders, my txt files cannot be read anymore.

My working directory is "E:/OM_Work"; my model is EVPkg1617.EVBasic, the file I need to read is "Sort1.txt".
The message that I receive is the following one:

stdout | OMEditInfo | <p>E:/OM_Work/EVPkg1617.EVbasic/EVPkg1617.EVbasic.exe -port=55543 -logFormat=xmltcp -override=startTime=0,stopTime=200,stepSize=0.1,tolerance=0.0001,solver=dassl,outputFormat=mat,variableFilter=.* -r=EVPkg1617.EVbasic_res.mat -w -lv=LOG_STATS</p>
stdout | info | <p>... loading "Cycle" from "Sort1.txt"<br>

assert | debug | <p>Not possible to open file "Sort1.txt": No such file or directory<br>

assert | info | <p>simulation terminated by an assertion at initialization</p>
stdout | error | <p>Simulation process failed. Exited with code -1.</p>

If I use the absolute address when loading the file for the table E:/OM_Work/Sort1.txt the file is loaded. So works, but it is not optimal because this implies hard-coding in the model the directory structure, creating additional issues when moving to other computers.

The same issue occurs if I copy the file in the OM-created subdirectory for my model.

In think that it's important that the file (in case non absolute path is given) should be found in the working directory (non in one of its subfolders), since the subfolders are created by OM, not by the user.

Attachments (2)

TestTxtFile.mo (813 bytes ) - added by massimo ceraolo 7 years ago.
Table.txt (95 bytes ) - added by massimo ceraolo 7 years ago.
C:\Work\TestFiles

Download all attachments as: .zip

Change History (13)

comment:1 by massimo ceraolo, 7 years ago

Description: modified (diff)

comment:2 by Martin Sjölund, 7 years ago

If you want to ship a file with a library, you should use loadResource

comment:3 by massimo ceraolo, 7 years ago

I would really appreciate if the old way, i. e. putting the file in the working directory, would work again. With the new file structure with subfolders it would be much better than before since the work folder now is not cluttered.

I manually distribute the text file to my studeny's.

Version 1, edited 7 years ago by massimo ceraolo (previous) (next) (diff)

in reply to:  2 comment:4 by massimo ceraolo, 7 years ago

Replying to sjoelund.se:

If you want to ship a file with a library, you should use loadResource

I played a little with loadResource.
It is very useful, as you say, when creating libraries, since it allows not ho hard-code the original PC file structure in the library. It is for instance perfect to link images to model descriptions.
It is sub-optimal in other cases, when you work with more limited packages:

  • when you want to use the same txt files for several packages, for instance containing efficiency maps of components, or physical trajectories to be followed, and you don't like replicating them (for maintenance reasons)
  • when you play around with packages, e.g. for teaching, and therefore you don't like to hard code the package name in the package code (modelica URIs must always contain the package name, AFAIK).

So I still believe that, in addition to loadResource, having a generic place where to put files to be just loaded (as it is with Dymola and used to be with OM) is not a bad idea. It allows avoiding to hard code absolute paths in the packages, even though the connection with resources remains a bit loose (which would be bad for libraries but is acceptable in other cases)

Last edited 7 years ago by massimo ceraolo (previous) (diff)

comment:5 by Francesco Casella, 7 years ago

See #2909

comment:6 by Francesco Casella, 7 years ago

Component: *unknown*OMEdit
Owner: changed from somebody to Adeel Asghar

I have discussed the requirments with @ceraolo, and I think definitely has a point. On one hand, if you have data which are specific to the models of a certain library (and needs to be distributed together with it), the the Library/Resources directory is the right place.

Conversely, if you need to load user-specific (not library-specific) data, it makes sense to load them from the working directory, while they definitely do not belong to the Resource directory. This is true in particular if the data is needed by a model that does not belong to a package.

Furthermore, as the same data input could be useful for different models, it is not a good idea to expect that input data are found in the directories with the models' names, because you'd need to unnecessarily copy them in multiple places. Also, the directories with the model's names are created when the model is run, but it is not possible to run it without the input data.

So, the root directory for relative file paths used in loadFile and similar functions should remain the working directory of OMEdit, as it was previously. The new directories that are created in there are only meant for file output.

comment:7 by Adeel Asghar, 7 years ago

Status: newaccepted

comment:8 by Adeel Asghar, 7 years ago

I probably need to set the environment for the simulation process.
Can you provide a simple test case?

comment:9 by massimo ceraolo, 7 years ago

Consider model M in TestTxtFile.mo. for the "loose" coupling with input files, they should be in the working directory. Here I expect model M to run with "Table.txt" being in the working directory root.

by massimo ceraolo, 7 years ago

Attachment: TestTxtFile.mo added

by massimo ceraolo, 7 years ago

Attachment: Table.txt added

C:\Work\TestFiles

comment:10 by Adeel Asghar, 7 years ago

Resolution: fixed
Status: acceptedclosed

comment:11 by massimo ceraolo, 7 years ago

Thanks a lot.
I will sure try it tomorrow.

Note: See TracTickets for help on using tickets.