Median aggregate not created during restore

39 views
Skip to first unread message

t.c....@gmail.com

unread,
Jan 8, 2024, 6:29:16 AMJan 8
to OpenREM
When restoring an openrem v0.10 export (postgres 10) into a fresh openrem v1.0 installation (postgres 14) I get the following error:

pg_restore: from TOC entry 1086; 1255 16424 AGGREGATE median(anyelement) openremuser
pg_restore: error: could not execute query: ERROR:  function array_append(anyarray, anyelement) does not exist
Command was: CREATE AGGREGATE public.median(anyelement) (
    SFUNC = array_append,
    STYPE = anyarray,
    INITCOND = '{}',
    FINALFUNC = public._final_median
);

I checked and the new database indeed lacks the aggregrate function "median". So far this doesn't seem to give any errors in the frontend, even when running queries with "median" enabled but this is probably something that needs fixing. How can I manually create the median function for the new database?

regards, Tim

Ed McDonagh

unread,
Jan 8, 2024, 7:45:27 AMJan 8
to t.c....@gmail.com, OpenREM
Hi Tim

You've hit this error: issue 928. We are not using that function in the new version of OpenREM - the median calculation method was replaced in issue 789.

What I don't understand is why you've hit it - I don't think I have seen that message any time I've done an upgrade, mostly following the upgrade_linux_new_server instructions, but I think I've tried them all.

Can you think of anything we should look at? Additional instructions that are missing?

Thanks

Ed

--
You received this message because you are subscribed to the Google Groups "OpenREM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrem+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/26a386f4-8498-46c1-a70b-9b54535d7dfbn%40googlegroups.com.

dpla...@gmail.com

unread,
Jan 8, 2024, 11:03:40 AMJan 8
to OpenREM
OpenREM no longer uses the database to calculate median values - it is done within python using Pandas data frames. This was changed when I replaced the Highcharts plotting code with plotly-based code.

t.c....@gmail.com

unread,
Jan 25, 2024, 6:39:29 AMJan 25
to OpenREM
Thanks both for the explanation!
When performing some validations between 0.10 and 1.0.0b we noticed small differences in the median calculation between both versions (for even number of measurements). Apparently these are caused by Python 3, which has changed rounding strategy (round(2.5) = 2 instead of 3). Doesn't rounding-up seem more appropriate for dosimetry purposes? On the other hand... probably the difference won't be significant in most cases?

regards, Tim

Op maandag 8 januari 2024 om 17:03:40 UTC+1 schreef dpla...@gmail.com:

Ed McDonagh

unread,
Jan 25, 2024, 9:42:59 AMJan 25
to t.c....@gmail.com, OpenREM
I'm sure David and I had a discussion about this, but all I can find is a reference to this issue when calculating skin maps: https://bitbucket.org/openrem/openrem/issues/946/skin-map-issue-for-python-3x

Do you remember more David?

Kind regards

Ed

--
You received this message because you are subscribed to the Google Groups "OpenREM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrem+u...@googlegroups.com.

dpla...@gmail.com

unread,
Feb 14, 2024, 9:26:11 AMFeb 14
to OpenREM
Hi,

Sorry for the late response. Python 3 uses "bankers rounding" by default, which is different to how I, as a scientist, would round numbers. It will make a small difference to the calculated chart values in some scenarios, but should have minimal effect when data points are being calculated from a large dataset.

Kind regards,

David

Reply all
Reply to author
Forward
0 new messages