View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001652 | OpenFOAM | Bug | public | 2015-04-08 15:13 | 2015-04-12 17:52 |
| Reporter | matthias | Assigned To | henry | ||
| Priority | high | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU/Linux | OS | Other | OS Version | (please specify) |
| Summary | 0001652: feature suggestion for DataEntry class | ||||
| Description | Hi, I'm using the DataEntry class to read two 1D functions via CSV file within the same patch description. My boundary condition is similar to oscillatingFixedValue but uses two different user-supplied wave functions. type oscillatingNormalVelocity; amplitude1 constant 1; amplitude2 constant 1; phase constant 1; frequency constant 1; func1 csvFile; func2 csvFile; csvFileCoeffs{ ... } The problem is that sources like CSV or Table read always the same csvFileCoeffs subdict and cannot differ between multiple files where different function values are stored. A workaround is the type vector using the first two columns as data input for the different functions but that's not very straightforward. An alternative could be to add an identifier to the csvFileCoeffs subdict as func1CsvFileCoeffs. Thus, each DataEntry instance could use its own subdict and would not interfere with the other ones. Best regards Matthias | ||||
| Tags | No tags attached. | ||||
|
|
I agree it would be sensible if the dictionary name for the coefficients could be provided as an optional argument to the constructor to allow more than one of these types to be constructed from the entries in a given dictionary. This will take a bit of reworking of the DataEntry class hierachy. We can put it on the feature request list but it is unlikely to get very high priority. Alternatively you could have a go at implemententing the functionality yourself or you could create specifically names sub-dictionaries each containing a csvFileCoeffs sub-dictionary in your BC. |
|
|
You are right but why not simply using the entryName as identifier in front of the coeff dict name? I changed two lines in the constructor of the CSV reader from TableBase<Type>(entryName, dict.subDict(type() + ext)), coeffs_(dict.subDict(type() + ext)), to TableBase<Type>(entryName, dict.subDict(entryName + type() + ext)), coeffs_(dict.subDict(entryName + type() + ext)), So the dict in my BC looks now ... func1 csvFile; func1csvFileCoeffs { ... } func2 csvFile; func2csvFileCoeffs { ... } and it works well. If using the entryName you have to modify only the sources which are using a separate coeff dicts as CSV, tableFile. |
|
|
I think your proposal is fine. Perpaps we could drop the type() part of the name altogether and use entryName instead or do you think it is preferable to maintain the type specification in the name of the coefficients sub-dict? |
|
|
I agree the type() part introduces no new information in this context and it would shorten the name of the coeff dict. |
|
|
I have made this change in OpenFOAM-dev: commit 838b8044ef63d5e020dce672799afbb604ee15f3 could you test it and if all is well I will make the same change to OpenFOAM-2.3.x |
|
|
I have tested the change and it works fine, all subdicts were treated separately. I think you can fix it in OF-2.3.x too. |
|
|
Resolved by commit 559ca6d585383dd73cf7cb38107e2d607818a30c |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-04-08 15:13 | matthias | New Issue | |
| 2015-04-08 16:14 | henry | Note Added: 0004576 | |
| 2015-04-08 17:00 | matthias | Note Added: 0004578 | |
| 2015-04-08 17:01 | matthias | Note Edited: 0004578 | |
| 2015-04-08 17:53 | henry | Note Added: 0004580 | |
| 2015-04-08 18:03 | matthias | Note Added: 0004581 | |
| 2015-04-08 21:26 | henry | Note Added: 0004582 | |
| 2015-04-12 15:57 | matthias | Note Added: 0004606 | |
| 2015-04-12 17:51 | henry | Note Added: 0004607 | |
| 2015-04-12 17:51 | henry | Status | new => resolved |
| 2015-04-12 17:51 | henry | Resolution | open => fixed |
| 2015-04-12 17:51 | henry | Assigned To | => henry |
