View source for Data structures in FPROPS

See also [[FPROPS]].

==Current Method==
At the time of writing the data needed for each fluid and correlation are declared as global C structures at compile time. For example, for water:
<source lang="c">
HelmholtzData helmholtz_data_water = {
	"water"
	, /* R */ WATER_R /* J/kg/K */
	, /* M */ 18.015242 /* kg/kmol -- G S Kell, J Phys Chem Ref Data (6) 1109 (1977) */
	, /* rho_star */ WATER_RHOC /* kg/m³ */
	, /* T_star */ WATER_TC /* K */

	, /* T_c */ WATER_TC
	, /* rho_c */ WATER_RHOC
	, /* T_t */ 273.16

	, 0.344 /* acentric factor, source: Reid, Prausnitz & Polling */
	, &ideal_data_water
    , 0 /* no helmholtz coeffs implemented yet...*/
	, (int)51 /* np */
	, (HelmholtzPowTerm[]){
		/* a_i, t_i, d_i, l_i */
		{0.12533547935523E-1, -0.5, 1, 0}
		,{0.78957634722828E1, 0.875, 1, 0}
		//...
		,{-0.11841182425981, 50, 6, 6}
	}
	, 3 /* gaussian terms */
	, (HelmholtzGausTerm[]){
		/* n, t, d, alpha, beta, gamma, epsilon */
		{-0.31306260323435e2, 0, 3, 20, 150, 1.21, 1}
		,{0.31546140237781e2, 1, 3, 20, 150, 1.21, 1}
		,{-0.25213154341695e4,4, 3, 20, 250, 1.25, 1}
	}
	, 2 /* critical terms */
	, (HelmholtzCritTerm[]){
		/* n, a, b, beta, A, B, C, D */
		{-0.14874640856724, 3.5, 0.85, 0.3, 0.32, 0.2, 28, 700}
		,{0.31806110878444, 3.5, 0.95, 0.3, 0.32, 0.2, 32, 800}
	}
};
</source>
This can be accessed from any function in the program and used to build up higher level structures such as the PureFluid data type.
There are a few disadvantages to handling data in this way, I won't go into all of them now but the main problem is that this method does not scale up well as we add more features to FPROPS. For example if we decide to add or remove a piece of data from a struct all of the initialisers in each fluid file have to be rewritten to match the new struct. 
==Future Method==
The key criterion that a future solution must meet is that the data must be stored in a way that is independent of the program itself.
===XML and Relax NG===
One possible solution to this problem has been investigated in some depth. This method involves storing the data in an XML file, with lots of markup to make the data easily accessible. This has the advantage of being easily parsed by FPROPS and any other programs that might decide to use the data down the line. Also, using XSL and CSS these XML files can be viewed in a browser in a very human readable way. It also allows for handling of some more complicated relations, for example there could be several different types of correlation for any fluid, and each correlation could have several slightly different sources, furthermore the correlations may have some order of preference or range of applicability. An XML schema should be able to handle these complexities in a sane manner.
An example of what an XML file might look like:
<source lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="dataTransform.xsl"?>
<fluid>
    <name>octane</name>
    <core source="Span and Wagner" rank="0">
        <M>114.231</M>
        <T_c>569.32</T_c>
        <P_c>2.497</P_c>
        <rho_c>234.90</rho_c>
        <omega>0.395</omega>
        <T_t>216.37</T_t>
    </core>
    <ideal source="Jaeschke and Schley" rank="0">
        <const>-8.32044648201</const>
        <lin>6.6832105268</lin>
        <Cp_star>OCTANE_R</Cp_star>
        <powerTerms number="5">
            <term><c>4.00662</c> <t>0</t></term>
            <term><c>4.00662</c> <t>0</t></term>
            <term><c>4.00662</c> <t>0</t></term>
            <term><c>4.00662</c> <t>0</t></term>
            <term><c>4.00662</c> <t>0</t></term>
		</powerTerms>
        <exponentialTerms number="1">
            <b>0.01243</b><beta>2</beta>
        </exponentialTerms>
    </ideal>
    <helmholtz source="Span and Wagner" rank="0">
        <powerTerms number="12">
            <term><a>0.10722545e1</a> <t>0.250</t> <d>1</d> <l>0</l></term>
            <term><a>0.10722545e1</a> <t>0.250</t> <d>1</d> <l>0</l></term>
            <term><a>0.10722545e1</a> <t>0.250</t> <d>1</d> <l>0</l></term>
            <term><a>0.10722545e1</a> <t>0.250</t> <d>1</d> <l>0</l></term>
            <term><a>0.10722545e1</a> <t>0.250</t> <d>1</d> <l>0</l></term>
            <term><a>0.10722545e1</a> <t>0.250</t> <d>1</d> <l>0</l></term>
            <term><a>0.10722545e1</a> <t>0.250</t> <d>1</d> <l>0</l></term>
            <term><a>0.10722545e1</a> <t>0.250</t> <d>1</d> <l>0</l></term>
            <term><a>0.10722545e1</a> <t>0.250</t> <d>1</d> <l>0</l></term>
            <term><a>0.10722545e1</a> <t>0.250</t> <d>1</d> <l>0</l></term>
            <term><a>0.10722545e1</a> <t>0.250</t> <d>1</d> <l>0</l></term>
            <term><a>0.10722545e1</a> <t>0.250</t> <d>1</d> <l>0</l></term>
        </powerTerms>
    </helmholtz>
</fluid>
</source>
The markup makes this file difficult for a human to read, however with XSL and CSS it can be transformed to a more readable format ([http://richard-towers.com/ASCEND/example.xml example])

The problem with this method is that, because of the complex markup, manual data entry is prohibitively slow. For this to be a workable solution there needs to be some solution to this problem.
One answer would be to have the files stored on a webserver and have an XHTML form for data entry calling a PHP (or python etc.) script to do the file handling. This would however be a departure from the SVN version control system which is a clear disadvantage.

One other solution would be to write a bespoke PyGTK GUI to deal with data entry, although this seems like overkill it would ensure properly formed documents, and data could be checked for plausibility at entry time.
: This is probably my preferred method [[User:RichardTowers|RichardTowers]] 14:06, 22 August 2011 (UTC)