search

OPM / opm-parser

http://www.opm-project.org
11 stars 44 forks source link

Default box #1193

Closed joakim-hove closed 6 years ago

joakim-hove commented 6 years ago

Allow the use use of defaults in the operational keywords like ADD and MULTIPLY:

This now works:

MULTIPLY
   'PERMX' 0.25 * * * * 4 4 /
/

to multiply PERMXin layer 4 - previously '*' could not be used.

joakim-hove commented 6 years ago

jenkins build this with downstreams please

joakim-hove commented 6 years ago

jenkins build this with downstreams please

OPMUSER commented 6 years ago

No, incorrect format should be

|MULTIPLY 'PERMX' 0.25 1 1 1 1 4 4 / /|

/E/

/I/

/P/

/C/

/E//quinox//I//nternational//P//etroleum //C//onsultants//P//te.//L//td./

/51 Goldhill Plaza, #07-10/11, Singapore 308900/

David Baxendale C. Math, MIMA, C. Sci, MEI

Managing Director

T:  +(65)-9173-7031

F:  +(65)-6732-2382

E: david.baxendale@eipc.co

On 2018-01-18 17:48, Joakim Hove wrote:

|MULTIPLY 'PERMX' 0.25 4 4 / /|

joakim-hove commented 6 years ago

No, incorrect format should be

Well - incorrect is incorrect - I can live with that.

atgeirr commented 6 years ago

Well - incorrect is incorrect - I can live with that.

I can't help but think there was some miscommunication here? Does the current code support *, 1* or both notations for defaulting?

joakim-hove commented 6 years ago

I can't help but think there was some miscommunication here?

Misunderstandings in written communication - that is our trade!

Does the current code support , 1 or both notations for defaulting?

The current code invokes the 100% normal opm-parser default handling scheme, which supports both * and 1* for defaulting. Actually the previous code - which is now removed, was a special casing to circumvent the default default handling - due to a misunderstanding of the documentation. So now we actually have simpler and more capable code!

andlaus commented 6 years ago

IIRC omitting the 1 in front of the asterisk is incorrect according to the ECL documentation but testing revealed that E100 eats such constructs just fine and there are apparently some decks out there which do this so opm-parser follows their great example as usual. maybe I don't remember this correctly, though. anyway, if above statement is correct this is a rare case where their implementation is more sensible than their documentation IMO.