View Issue Details

IDProjectCategoryView StatusLast Update
0001652OpenFOAMBugpublic2015-04-12 17:52
Reportermatthias Assigned Tohenry  
PriorityhighSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSOtherOS Version(please specify)
Summary0001652: feature suggestion for DataEntry class
DescriptionHi,

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
TagsNo tags attached.

Activities

henry

2015-04-08 16:14

manager   ~0004576

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.

matthias

2015-04-08 17:00

reporter   ~0004578

Last edited: 2015-04-08 17:01

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.

henry

2015-04-08 17:53

manager   ~0004580

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?

matthias

2015-04-08 18:03

reporter   ~0004581

I agree the type() part introduces no new information in this context and it would shorten the name of the coeff dict.

henry

2015-04-08 21:26

manager   ~0004582

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

matthias

2015-04-12 15:57

reporter   ~0004606

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.

henry

2015-04-12 17:51

manager   ~0004607

Resolved by commit 559ca6d585383dd73cf7cb38107e2d607818a30c

Issue History

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