OPM / opm-common

Common components for OPM, in particular build system (cmake).

Home Page:http://www.opm-project.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

potential problem in handling multiple PVT region PVDG keywords

GitPaean opened this issue · comments

in connection with the issue OPM/opm-simulators#4464 .

I modified the PVDG keyword as the following

PVDG 
                   1            1.06318             0.0112
                17.6            0.05968              0.012/
  /
                     1            1.06318             0.0112
                17.6            0.05968              0.012
                34.1            0.03004             0.0124 /
  /
                     1            1.06318             0.0112
                17.6            0.05968              0.012
                34.1            0.03004             0.0124
                50.7            0.01983             0.0129 /
  /
                     1            1.06318             0.0112
                17.6            0.05968              0.012
                34.1            0.03004             0.0124
                50.7            0.01983             0.0129
                67.2            0.01471             0.0135/
  /

In that data file (https://www.dropbox.com/scl/fo/orimdjhc1wu1t981c8yuv/h?dl=0&rlkey=30qgt30cjixc1x9ishnk8meb2), the PVT region number from the TABDIMS is 8.

And I output the table information with

            std::cout << keywordName << " table " << tableIdx << " has " << dataItem.data_size() << " entries " << std::endl;

in the for loop inside the

    void TableManager::initSimpleTableContainer(const Deck& deck,
                                                const std::string& keywordName,
                                                const std::string& tableName,
                                                size_t numTables) {

below line

const auto& dataItem = tableKeyword.getRecord( tableIdx ).getItem("DATA");

The output is as follows,

PVDG table 0 has 6 entries 
PVDG table 1 has 0 entries 
PVDG table 2 has 9 entries 
PVDG table 3 has 0 entries 
PVDG table 4 has 12 entries 
PVDG table 5 has 0 entries 
PVDG table 6 has 15 entries 
PVDG table 7 has 0 entries 

which is rather strange to me. Do we have some explanation/understanding over this? Maybe @bska has some ideas since you touched this part of the code?

Thanks.

So far it just looks confusing to me, and I am not suggesting it is a bug.

Do we have some explanation/understanding over this?

Yes. We check the .size() of dataItem in the three-way branch.

  1. If the size is positive, meaning we have table data, then we initialise the table from that data and record that table as the last "complete" table.

  2. Otherwise, i.e., when dataItem.size() == 0, we check if we're not the first table (index == 0). In that case, we initialise the tableIdx-th table as a copy of the last complete table

  3. Otherwise, i.e., when dataItem.size() == 0 && tableIdx == 0, we fail the table construction since the first table cannot be defaulted.

Thanks for the response. But my actual question is the following, why the output for the dataItem.data_size() is as the following,

PVDG table 0 has 6 entries 
PVDG table 1 has 0 entries 
PVDG table 2 has 9 entries 
PVDG table 3 has 0 entries 
PVDG table 4 has 12 entries 
PVDG table 5 has 0 entries 
PVDG table 6 has 15 entries 
PVDG table 7 has 0 entries 

Now I understand is how we use the / in the input,

In the following setup,

PVDG 
                   1            1.06318             0.0112
                17.6            0.05968              0.012/
  /
                     1            1.06318             0.0112
                17.6            0.05968              0.012
                34.1            0.03004             0.0124 /
  /
                     1            1.06318             0.0112
                17.6            0.05968              0.012
                34.1            0.03004             0.0124
                50.7            0.01983             0.0129 /
  /
                     1            1.06318             0.0112
                17.6            0.05968              0.012
                34.1            0.03004             0.0124
                50.7            0.01983             0.0129
                67.2            0.01471             0.0135/
  /

between the two / in the middle of the input, we created an empty table there. Not totally sure whether it is the way should be done to me unless verified, but I understand the strange output to me. Sorry for the noise.

n the middle of the input, we created an empty table there.

Kind of, but not really. The low-level text reader expects PVDG to have NTVPT (= TABDIMS(2)) records. At that level of the input reading, there is no notion of "tables", only keywords and number of records. Since there is no data in the 2nd, 4th, 6th, and 8th records here (NTPVT == 8) the reader defers to higher-level logic, in this case TableManager::initSimpleTableContainer(), to interpret/handle the situation. The input format stipulates that empty tables, provided they're not the first, are to be interpreted as copies of the previous full table and that's the behaviour we have here. The same goes for saturation functions and a number of other table keywords.

Thanks for the explanation. My problem is that I did not realize between two /s in the following context, there will be an empty record (data_size() == 0) is generated during parsing.

                   1            1.06318             0.0112
                17.6            0.05968              0.012  **/**
  **/** 
                     1            1.06318             0.0112

The confusion is well addressed to me. I am closing the issue now.