[RFC PATCH] gas model: use virial cubic polynomial form

[Robert Helling]

> On 04.03.2016, at 06:46, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> 
> ---
> 
> NOTE THE "RFC" part. I'm not sure this is worth it. It came from the G+
> discussion: the virial form is apparently the preferred form for the Z
> calculation and the difference to the pure cubic least-square is minimal.
> 
> And it does generate better code, just because there are fewer constants
> and fewer FP operations and we can delay adding the 1.0 term until after
> the gas mix, rather than doing it for each gas.
> 
> At the same time, I'm not exactly claiming that this really helps make the
> code obvious.  Maybe it's premature optimization. And really, considering
> that we don't even inline the "get_o2()" trivial function etc, the code
> generation really isn't very optional.
> 
> So for this to make sense, we'd need to feel that performance matters. We
> *do* end up doing the gas use for each plot point, so it's not like this
> function might not get called a lot.
> 
> But compiler options will change the code generation even more than this
> ever will, and aggressive compiler optimizations would have made the old
> code better too (ie just inlining and CSE on the pressure power series
> would do good things to the thing without this patch too).
> 
> In other words: I think this patch is correct, and it *does* make the code
> faster. But do we even care at this point?
> 

Your patch looks good and I would not worry too much about shaving off a few cycles here. We are talking about shaving off a few hundred floating point operations per profile.

But if you really wanted to tweet things, there are two things that could be factored out: Don’t divide o2 and he by 1000.0, rather do that only once in the end. And instead of doing the weighted average of the Z factors, you could equivalently do the weighted average of the coefficients of the polynomial. That you would need to do only once per gas and save those values as we compute Z for many pressures for the same gas.

But I think we are deep in over-engineering territory here.

> +	double o2, he;
> +	double x1, x2, x3;
> +	double Z;
> +
> +	o2 = get_o2(gas) / 1000.0;
> +	he = get_he(gas) / 1000.0;
> +
> +	x1 = bar; x2 = x1*x1; x3 = x2*x1;
> +
> +	Z = virial_m1(o2_coefficients, x1, x2, x3) * o2 +
> +	    virial_m1(he_coefficients, x1, x2, x3) * he +
> +	    virial_m1(n2_coefficients, x1, x2, x3) * (1.0 - o2 - he);
> +
> +	/*
> +	 * We add the 1.0 at the very end - the linear mixing of the
> +	 * three 1.0 terms is still 1.0 regardless of the gas mix.
> +	 */
> +	return Z + 1.0;
> 

Best
Robert


--
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO
Robert C. Helling     Elite Master Course Theoretical and Mathematical Physics
                      Scientific Coordinator
                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik
                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
                      http://www.atdotde.de

Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    and
DCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160304/299ad6c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160304/299ad6c2/attachment-0001.sig>