#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 )
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)
Change History (13)
comment:1 by , 7 years ago
Description: | modified (diff) |
---|
follow-up: 4 comment:2 by , 7 years ago
comment:3 by , 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 students.
comment:4 by , 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)
comment:6 by , 7 years ago
Component: | *unknown* → OMEdit |
---|---|
Owner: | changed from | to
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 , 7 years ago
Status: | new → accepted |
---|
comment:8 by , 7 years ago
I probably need to set the environment for the simulation process.
Can you provide a simple test case?
comment:9 by , 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 , 7 years ago
Attachment: | TestTxtFile.mo added |
---|
comment:10 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Fixed in 1be2a0/OMCompiler and 63db4c/OMEdit.
If you want to ship a file with a library, you should use loadResource