You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the Eclipse documentation, the vector parameter values in UNSMRY are stored with the data type REAL, which is described as single precision (4 byte) floating point reals.
In ecl, at least from the python side (think also C++ side, at least what I've seen), all values are returned as float64, giving a substantial memory overhead. For a single simulation, it doesn't have much to say, but if you aggregate to ensembles, the difference is significant.
Would be nice to be able to get float32 directly (as an optional flag to avoid when requesting e.g. numpy arrays or pandas DataFrames (preferably also on the C++ side to limit memory usage also on that side, though the python output of the bindings are the most important for my personal use).
The text was updated successfully, but these errors were encountered:
We did some Sherlock Holmes-ing. It seems very feasible. While the following isn't the only places where we end up while reading UNSMRY data, it seems to be one of the more important places. Notice that we're reading a float and casting it to double.
What remains is to figure out the other places (seems like a few caching and/or default values that also should be floats?) and also what to do with the current API. My hypothesis is that casting float -> double -> float is a lossless operation, in which case this can just be the default and we could provide the user with a different function, ie. pandas_frame32() or something for backwards compatibility, and then make 32-bit the default in ecl3.
According to the Eclipse documentation, the vector parameter values in UNSMRY are stored with the data type
REAL
, which is described as single precision (4 byte) floating point reals.In
ecl
, at least from thepython
side (think alsoC++
side, at least what I've seen), all values are returned asfloat64
, giving a substantial memory overhead. For a single simulation, it doesn't have much to say, but if you aggregate to ensembles, the difference is significant.Would be nice to be able to get
float32
directly (as an optional flag to avoid when requesting e.g. numpy arrays or pandas DataFrames (preferably also on theC++
side to limit memory usage also on that side, though thepython
output of the bindings are the most important for my personal use).The text was updated successfully, but these errors were encountered: