Jump to: navigation, search

Ideas for improved API for FPROPS... for discussion

  • Use of FPROPS from Python is currently not intuitive (especially compared with freesteam). Much better approach arises from object-oriented approach, eg something like

import fprops
# get a 'fluid' object
F = fprops.fluid("toluene")

# get a 'state' object
p = 100e3
T = 400e3
S = F.set_ph(p,h)
T = S.T
print "p = %f, h = %f --> T = %f"
  • How does this work when we start wanting to use alternative fluid property correlations?

# some additional parameter to specify the EOS that we want to use...?
F = fprops.fluid("toluene",eos="MBWR")
  • What about when we start supporting fluid mixtures?

# added parameter to specify components
F = fprops.mixture(["ammonia","nitrogen","hydrogen"])
# maybe also specify mass fractions?
F = fprops.mixture({"ammonia":0.9, "nitrogen": 0.05, "hydrogen": 0.05})
# or maybe mass fractions get specified later (but how is the ordering determined?)
  • What gets stored in these 'state' objects for pure components?
    • pointer to 'fluid' object
    • T
    • rho
    • rho_f, where already evaluated
    • rho_g, where already evaluated
    • p_sat, where already evaluated
  • What gets stored in the 'fluid' objects?
    • EOS data
    • any precalculated data not contained in the source data file (eg p_c, rho_f_t, possibly other stuff)
  • What about 'mixture' objects?
    • pointers to 'fluid' objects
    • mass fractions? or should those be in a 'mixturestate object??
  • How do we deal with chemical reactions, and changing mass fractions... can we handle that? What is the mechanism?

Jpye 08:41, 27 May 2011 (UTC)

This looks good, is there a book or tutorial about writing python bindings? I've never played with bindings before and this is the best I could find on google... RichardTowers 11:04, 27 May 2011 (UTC)
We use the tool 'swig' to create Python bindings. Some details here. There's a bit to learn there but you might like to do a little reading. 'Direct' wrapping such as shown at the link you gave is not efficient, I think. Swig wrapping of C is quite good. Take a look at my freesteam project (version 2.x) for an example of how I think we should aim to proceed with FPROPS (roughly). But here is more about designing the right architecture so that various options can be accommodated, eg access from ASCEND, access from Python, access from C/C++. Jpye 12:17, 27 May 2011 (UTC)

Data structures for declaration in C code

As a precursor to an XML-based solution for data structures in FPROPS we will try to get a good intermediate C data structure up and running.

Since VdW, RK, SRK and PR EOSs all need only 'cubic equation of state data', namely p_c, T_c and omega in order to be specified, we can allow a data file to specify just these things (plus molar mass M for per-mass calculation), and then the user at runtime can specify which cubic EOS is to be used... it doesn't have to be coded into the data file (if we wanted to specify a preference of cubic EOS for that material, that could be added within the cubic data perhaps?)

For a complete cubic EOS representation of fluid properties, we still need CP0 data, and that may or may not be the same CP0 data as used by another correlation equation. So an input data file will need to be able to include multiple CP0 correlations. Since CP0 will always be referred to from an EOS, the EOS can provide the molecular mass and zero-offsets for h and s etc as required.

Jpye 14:12, 23 August 2011 (UTC)


Some useful notes on fugacity: