ASCEND - User contributions [en]

Data structures in FPROPS

2011-08-22T14:06:23Z

RichardTowers: My thoughts on data 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">
0.01243<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)

User:RichardTowers

2011-08-17T13:33:18Z

RichardTowers: /* Progress reports */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

Browse code: {{srcbranchdir|richard|models/johnpye/fprops}}
== Goals ==
Goals have been updated as of 4 August 2011 and are shown below. The initial project goals are not vastly different, but can be seen in [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application].

# Complete integration of PR EOS in FPROPS. All the departure functions should be implemented, tested, working, and connected with the ideal gas functions, for calculation of all the 'raw' properties complete and correct.
# PR EOS should be tested with the current sat.c Akasaka approach for calculating single-fluid saturate mixture states. Algorthim should be working and giving reasonable values, and reasonable error messages if failing.
# Existing Helmholtz code should be modified to use the new data structures and all existing tests should still be working correctly with no changes having arising from the code refactor.
# Existing Python and ASCEND bindings need to be updated to work with all the new code, and be operating correctly.
# Existing build tools should be updated to operate on the new code, and FPROPS built and tested using SCons on all three operating systems.
# Progress on XML and XSLT tools for FPROPS should be documented, with remaining tasks/intentions detailed.
# FPROPS wiki page updated with information about the modifications completed, new functionality, etc.
# Convert data from RPP book to C data structures to increase fluid support to 50+ fluids.

== Progress reports ==
'''17th August 2011'''

Peng robinson and helmholtz in agreement on pressures now. If I can just get the helmholtz energy departure function working then it'll be working in time for the deadline.

'''12th August 2011'''

Difficult week, main computer broken, difficulties compiling on second. Finally succeeded in running scons. Work on python bindings, they're working now but need tidying up.

Thought for the day: SWIG is ''really'' clever.

'''4th August 2011'''

Helmholtz calculations now work with the new data structures. All fluids and tests have been updated and work (except for ethanol and isohexane who's tests report small and large errors respectively). Peng-Robinson appears to give almost completely different values to helmholtz even for pressure which should be trivial. This is '''not''' expected, and the cause needs investigating before we can move into more FPROPS-esque support for ideal and saturation calculations. John emailed with an updated list of goals which are updated above.

'''25th July 2011'''

Peng-Robinson EOS now successfully calculates <math>p(V,T)</math>, <math>V(p,T)</math> and <math>\Delta h(V,T)</math>, <math>\Delta s(V,T)</math>. Redlich-Kwong EOS also works, but has additional '''untested''' support for a,u,g departure functions. Once the two new EOSs are integrated with current ideal and saturation calculations then we'll have two new EOSs.

'''15th July 2011'''

Most of the way to a working implementation of the Peng-Robinson equation of state, there are still some issues to be resolved with respect to ideal properties and internal representation of data.

XML data file structure decided upon and a human readable transformation written, still require an input form to create these files. Will also need to modify cToXML to create files for the existing fluids (Note: Will have to be careful with rounding).

'''4th July 2011'''

Having discussed flexibility with regards to equation of state decided on the future structure of the program. Using various structs and unions fprops now has a skeleton capable of supporting several possible equations.

Still to do in this area: Actually implement other EOSs (peng-robinson first), Refactor FPROPS to fit with new way of doing things.

'''24th June 2011'''

Switched to Mac OS X for development, switched to the Xcode IDE for editing, hopefully the overheads in learning the new system will be worth it. Spoke to John about support for multiple equations of state, created a couple of files ready to start experimenting.

'''20th June 2011'''

All fluid files converted from source to XML, parser demonstrated to work for every file tried so far. Further features (multiple correlations from multiple sources etc.) should be relatively easy to implement now. Acquired a copy of Sandler "Chemical and Engineering Thermodynamics" which will be helpful in sorting out implementations of the cubic equations of state.

'''17 June 2011'''

Finished writing an xml parser and translating c data files to xml .fluid files. readFluidFile() from parser.c will now load data at run time. There's still a few features to be implemented here but it's up and running now.

'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/xml/hydrogen.fluid?view=markup hydrogen.fluid]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/parserMkII.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[Redlich Kwong EOS in FPROPS|Redlich Kwong]] & [[PengRobinson EOS in FPROPS|Peng Robinson]] cubic EOSs. See {{srcbranch|richard|models/johnpye/fprops/pengrob.c}},
{{srcbranch|richard|models/johnpye/fprops/pengrob.h}},
{{srcbranch|richard|models/johnpye/fprops/redkw.c}} and
{{srcbranch|richard|models/johnpye/fprops/redkw.h}} for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

One of the main challenges here is to write functions which can take any correlation data struct as an input, decide which correlation to use, and return the desired value. After some consultation with John, we've decided on a struct containing all of the data and pointers to the various functions. A union is used to enable different types of data to be passed to functions with the same arguments.
<source lang="c">
/** Enumerate EOS correlations
*/
enum eos{
pengrob,
redkw,
helmholtz,
mbwr //etc.
};

/** Union for equation of state data
*/
typedef union eos_tag{
HelmholtzData* helmholtzData;
CubicData* cubicData;
//etc...
} EosData;

/** Definition of a fluid property function pointer
*/
typedef double (*propFnPtr)(double,double,const EosData*);

/**
Structure pointing to the necessary data and functions to calculate
fluid properties.
*/
typedef struct pureFluid{
enum eos type;
IdealData *idealData;
EosData *eosData;
//Pointers to departure functions
propFnPtr p_fn;
propFnPtr u_fn;
propFnPtr h_fn;
propFnPtr s_fn;
propFnPtr a_fn;
propFnPtr cv_fn;
propFnPtr cp_fn;
propFnPtr w_fn;
propFnPtr g_fn;
} pureFluid;
</source>

The structure can be created as follows, and then the function pointers can simply be followed to the correct function.
<source lang="c">
EosData eosData={.cubicData=&cData};
pureFluid fluidData={
pengrob,
&iData,
&eosData,
//Pointers to departure functions
pengrob_p,
pengrob_u_depart,
pengrob_h_depart,
pengrob_s_depart,
pengrob_a_depart,
pengrob_cv,
pengrob_cp,
pengrob_w,
pengrob_g_depart
};

double p=fluidData.p_fn(T,rho,fluidData.eosData);
</source>
[[Category:GSOC2011]]
[[Category:ASCEND Contributors]]

PengRobinson EOS in FPROPS

2011-08-16T17:49:09Z

RichardTowers: /* Overview */

User:RichardTowers

2011-08-12T13:28:08Z

RichardTowers: /* Progress reports */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

Browse code: {{srcbranchdir|richard|models/johnpye/fprops}}
== Goals ==
Goals have been updated as of 4 August 2011 and are shown below. The initial project goals are not vastly different, but can be seen in [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application].

# Complete integration of PR EOS in FPROPS. All the departure functions should be implemented, tested, working, and connected with the ideal gas functions, for calculation of all the 'raw' properties complete and correct.
# PR EOS should be tested with the current sat.c Akasaka approach for calculating single-fluid saturate mixture states. Algorthim should be working and giving reasonable values, and reasonable error messages if failing.
# Existing Helmholtz code should be modified to use the new data structures and all existing tests should still be working correctly with no changes having arising from the code refactor.
# Existing Python and ASCEND bindings need to be updated to work with all the new code, and be operating correctly.
# Existing build tools should be updated to operate on the new code, and FPROPS built and tested using SCons on all three operating systems.
# Progress on XML and XSLT tools for FPROPS should be documented, with remaining tasks/intentions detailed.
# FPROPS wiki page updated with information about the modifications completed, new functionality, etc.
# Convert data from RPP book to C data structures to increase fluid support to 50+ fluids.

== Progress reports ==
'''12th August 2011'''

Difficult week, main computer broken, difficulties compiling on second. Finally succeeded in running scons. Work on python bindings, they're working now but need tidying up.

Thought for the day: SWIG is ''really'' clever.

'''4th August 2011'''

Helmholtz calculations now work with the new data structures. All fluids and tests have been updated and work (except for ethanol and isohexane who's tests report small and large errors respectively). Peng-Robinson appears to give almost completely different values to helmholtz even for pressure which should be trivial. This is '''not''' expected, and the cause needs investigating before we can move into more FPROPS-esque support for ideal and saturation calculations. John emailed with an updated list of goals which are updated above.

'''25th July 2011'''

Peng-Robinson EOS now successfully calculates <math>p(V,T)</math>, <math>V(p,T)</math> and <math>\Delta h(V,T)</math>, <math>\Delta s(V,T)</math>. Redlich-Kwong EOS also works, but has additional '''untested''' support for a,u,g departure functions. Once the two new EOSs are integrated with current ideal and saturation calculations then we'll have two new EOSs.

'''15th July 2011'''

Most of the way to a working implementation of the Peng-Robinson equation of state, there are still some issues to be resolved with respect to ideal properties and internal representation of data.

XML data file structure decided upon and a human readable transformation written, still require an input form to create these files. Will also need to modify cToXML to create files for the existing fluids (Note: Will have to be careful with rounding).

'''4th July 2011'''

Having discussed flexibility with regards to equation of state decided on the future structure of the program. Using various structs and unions fprops now has a skeleton capable of supporting several possible equations.

Still to do in this area: Actually implement other EOSs (peng-robinson first), Refactor FPROPS to fit with new way of doing things.

'''24th June 2011'''

Switched to Mac OS X for development, switched to the Xcode IDE for editing, hopefully the overheads in learning the new system will be worth it. Spoke to John about support for multiple equations of state, created a couple of files ready to start experimenting.

'''20th June 2011'''

All fluid files converted from source to XML, parser demonstrated to work for every file tried so far. Further features (multiple correlations from multiple sources etc.) should be relatively easy to implement now. Acquired a copy of Sandler "Chemical and Engineering Thermodynamics" which will be helpful in sorting out implementations of the cubic equations of state.

'''17 June 2011'''

Finished writing an xml parser and translating c data files to xml .fluid files. readFluidFile() from parser.c will now load data at run time. There's still a few features to be implemented here but it's up and running now.

'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/xml/hydrogen.fluid?view=markup hydrogen.fluid]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/parserMkII.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[Redlich Kwong EOS in FPROPS|Redlich Kwong]] & [[PengRobinson EOS in FPROPS|Peng Robinson]] cubic EOSs. See {{srcbranch|richard|models/johnpye/fprops/pengrob.c}},
{{srcbranch|richard|models/johnpye/fprops/pengrob.h}},
{{srcbranch|richard|models/johnpye/fprops/redkw.c}} and
{{srcbranch|richard|models/johnpye/fprops/redkw.h}} for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

One of the main challenges here is to write functions which can take any correlation data struct as an input, decide which correlation to use, and return the desired value. After some consultation with John, we've decided on a struct containing all of the data and pointers to the various functions. A union is used to enable different types of data to be passed to functions with the same arguments.
<source lang="c">
/** Enumerate EOS correlations
*/
enum eos{
pengrob,
redkw,
helmholtz,
mbwr //etc.
};

/** Union for equation of state data
*/
typedef union eos_tag{
HelmholtzData* helmholtzData;
CubicData* cubicData;
//etc...
} EosData;

/** Definition of a fluid property function pointer
*/
typedef double (*propFnPtr)(double,double,const EosData*);

/**
Structure pointing to the necessary data and functions to calculate
fluid properties.
*/
typedef struct pureFluid{
enum eos type;
IdealData *idealData;
EosData *eosData;
//Pointers to departure functions
propFnPtr p_fn;
propFnPtr u_fn;
propFnPtr h_fn;
propFnPtr s_fn;
propFnPtr a_fn;
propFnPtr cv_fn;
propFnPtr cp_fn;
propFnPtr w_fn;
propFnPtr g_fn;
} pureFluid;
</source>

The structure can be created as follows, and then the function pointers can simply be followed to the correct function.
<source lang="c">
EosData eosData={.cubicData=&cData};
pureFluid fluidData={
pengrob,
&iData,
&eosData,
//Pointers to departure functions
pengrob_p,
pengrob_u_depart,
pengrob_h_depart,
pengrob_s_depart,
pengrob_a_depart,
pengrob_cv,
pengrob_cp,
pengrob_w,
pengrob_g_depart
};

double p=fluidData.p_fn(T,rho,fluidData.eosData);
</source>
[[Category:GSOC2011]]
[[Category:ASCEND Contributors]]

Talk:Porting to Mac

2011-08-10T13:43:01Z

RichardTowers:

I'm having some problems having moved to OS X 10.7 (Lion). For starters it appears that SWIG no longer comes bundled with Xcode (4.1), so macports is required, this has the knock on effect of causing problems buliding pyGTK. More on this as I work through the issues. [[User:RichardTowers|RichardTowers]] 13:39, 10 August 2011 (UTC)

Talk:Porting to Mac

2011-08-10T13:39:42Z

RichardTowers: OS X Lion

I'm having some problems having moved to OS X 10.7 (Lion). For starters it appears that SWIG no longer comes bundled with Xcode, so macports is required, this has the knock on effect of causing problems buliding pyGTK. More on this as I work through the issues. [[User:RichardTowers|RichardTowers]] 13:39, 10 August 2011 (UTC)

User:RichardTowers

2011-08-04T18:51:04Z

RichardTowers: /* Goals */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

Browse code: {{srcbranchdir|richard|models/johnpye/fprops}}
== Goals ==
An updated list of goals can be found below. For an idea of my initial goals have a look at [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application].

== Progress reports ==
'''4th August 2011'''

Helmholtz calculations now work with the new data structures. All fluids and tests have been updated and work (except for ethanol and isohexane who's tests report small and large errors respectively). Peng-Robinson appears to give almost completely different values to helmholtz even for pressure which should be trivial. This is '''not''' expected, and the cause needs investigating before we can move into more FPROPS-esque support for ideal and saturation calculations. John emailed with an updated list of goals which are as follows:
* Complete integration of PR EOS in FPROPS. All the departure functions should be implemented, tested, working, and connected with the ideal gas functions, for calculation of all the 'raw' properties complete and correct.
* PR EOS should be tested with the current sat.c Akasaka approach for calculating single-fluid saturate mixture states. Algorthim should be working and giving reasonable values, and reasonable error messages if failing.
* Existing Helmholtz code should be modified to use the new data structures and all existing tests should still be working correctly with no changes having arising from the code refactor.
* Existing Python and ASCEND bindings need to be updated to work with all the new code, and be operating correctly.
* Existing build tools should be updated to operate on the new code, and FPROPS built and tested using SCons on all three operating systems.
* Progress on XML and XSLT tools for FPROPS should be documented, with remaining tasks/intentions detailed.
* FPROPS wiki page updated with information about the modifications completed, new functionality, etc.
* Convert data from RPP book to C data structures to increase fluid support to 50+ fluids.

'''25th July 2011'''

Peng-Robinson EOS now successfully calculates <math>p(V,T)</math>, <math>V(p,T)</math> and <math>\Delta h(V,T)</math>, <math>\Delta s(V,T)</math>. Redlich-Kwong EOS also works, but has additional '''untested''' support for a,u,g departure functions. Once the two new EOSs are integrated with current ideal and saturation calculations then we'll have two new EOSs.

'''15th July 2011'''

Most of the way to a working implementation of the Peng-Robinson equation of state, there are still some issues to be resolved with respect to ideal properties and internal representation of data.

XML data file structure decided upon and a human readable transformation written, still require an input form to create these files. Will also need to modify cToXML to create files for the existing fluids (Note: Will have to be careful with rounding).

'''4th July 2011'''

Having discussed flexibility with regards to equation of state decided on the future structure of the program. Using various structs and unions fprops now has a skeleton capable of supporting several possible equations.

Still to do in this area: Actually implement other EOSs (peng-robinson first), Refactor FPROPS to fit with new way of doing things.

'''24th June 2011'''

Switched to Mac OS X for development, switched to the Xcode IDE for editing, hopefully the overheads in learning the new system will be worth it. Spoke to John about support for multiple equations of state, created a couple of files ready to start experimenting.

'''20th June 2011'''

All fluid files converted from source to XML, parser demonstrated to work for every file tried so far. Further features (multiple correlations from multiple sources etc.) should be relatively easy to implement now. Acquired a copy of Sandler "Chemical and Engineering Thermodynamics" which will be helpful in sorting out implementations of the cubic equations of state.

'''17 June 2011'''

Finished writing an xml parser and translating c data files to xml .fluid files. readFluidFile() from parser.c will now load data at run time. There's still a few features to be implemented here but it's up and running now.

'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/xml/hydrogen.fluid?view=markup hydrogen.fluid]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/parserMkII.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[Redlich Kwong EOS in FPROPS|Redlich Kwong]] & [[PengRobinson EOS in FPROPS|Peng Robinson]] cubic EOSs. See {{srcbranch|richard|models/johnpye/fprops/pengrob.c}},
{{srcbranch|richard|models/johnpye/fprops/pengrob.h}},
{{srcbranch|richard|models/johnpye/fprops/redkw.c}} and
{{srcbranch|richard|models/johnpye/fprops/redkw.h}} for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

One of the main challenges here is to write functions which can take any correlation data struct as an input, decide which correlation to use, and return the desired value. After some consultation with John, we've decided on a struct containing all of the data and pointers to the various functions. A union is used to enable different types of data to be passed to functions with the same arguments.
<source lang="c">
/** Enumerate EOS correlations
*/
enum eos{
pengrob,
redkw,
helmholtz,
mbwr //etc.
};

/** Union for equation of state data
*/
typedef union eos_tag{
HelmholtzData* helmholtzData;
CubicData* cubicData;
//etc...
} EosData;

/** Definition of a fluid property function pointer
*/
typedef double (*propFnPtr)(double,double,const EosData*);

/**
Structure pointing to the necessary data and functions to calculate
fluid properties.
*/
typedef struct pureFluid{
enum eos type;
IdealData *idealData;
EosData *eosData;
//Pointers to departure functions
propFnPtr p_fn;
propFnPtr u_fn;
propFnPtr h_fn;
propFnPtr s_fn;
propFnPtr a_fn;
propFnPtr cv_fn;
propFnPtr cp_fn;
propFnPtr w_fn;
propFnPtr g_fn;
} pureFluid;
</source>

The structure can be created as follows, and then the function pointers can simply be followed to the correct function.
<source lang="c">
EosData eosData={.cubicData=&cData};
pureFluid fluidData={
pengrob,
&iData,
&eosData,
//Pointers to departure functions
pengrob_p,
pengrob_u_depart,
pengrob_h_depart,
pengrob_s_depart,
pengrob_a_depart,
pengrob_cv,
pengrob_cp,
pengrob_w,
pengrob_g_depart
};

double p=fluidData.p_fn(T,rho,fluidData.eosData);
</source>
[[Category:GSOC2011]]

User:RichardTowers

2011-08-04T15:21:25Z

RichardTowers: New goals

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

Browse code: {{srcbranchdir|richard|models/johnpye/fprops}}
== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* [[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''4th August 2011'''

Helmholtz calculations now work with the new data structures. All fluids and tests have been updated and work (except for ethanol and isohexane who's tests report small and large errors respectively). Peng-Robinson appears to give almost completely different values to helmholtz even for pressure which should be trivial. This is '''not''' expected, and the cause needs investigating before we can move into more FPROPS-esque support for ideal and saturation calculations. John emailed with an updated list of goals which are as follows:
* Complete integration of PR EOS in FPROPS. All the departure functions should be implemented, tested, working, and connected with the ideal gas functions, for calculation of all the 'raw' properties complete and correct.
* PR EOS should be tested with the current sat.c Akasaka approach for calculating single-fluid saturate mixture states. Algorthim should be working and giving reasonable values, and reasonable error messages if failing.
* Existing Helmholtz code should be modified to use the new data structures and all existing tests should still be working correctly with no changes having arising from the code refactor.
* Existing Python and ASCEND bindings need to be updated to work with all the new code, and be operating correctly.
* Existing build tools should be updated to operate on the new code, and FPROPS built and tested using SCons on all three operating systems.
* Progress on XML and XSLT tools for FPROPS should be documented, with remaining tasks/intentions detailed.
* FPROPS wiki page updated with information about the modifications completed, new functionality, etc.
* Convert data from RPP book to C data structures to increase fluid support to 50+ fluids.

'''25th July 2011'''

Peng-Robinson EOS now successfully calculates <math>p(V,T)</math>, <math>V(p,T)</math> and <math>\Delta h(V,T)</math>, <math>\Delta s(V,T)</math>. Redlich-Kwong EOS also works, but has additional '''untested''' support for a,u,g departure functions. Once the two new EOSs are integrated with current ideal and saturation calculations then we'll have two new EOSs.

'''15th July 2011'''

Most of the way to a working implementation of the Peng-Robinson equation of state, there are still some issues to be resolved with respect to ideal properties and internal representation of data.

XML data file structure decided upon and a human readable transformation written, still require an input form to create these files. Will also need to modify cToXML to create files for the existing fluids (Note: Will have to be careful with rounding).

'''4th July 2011'''

Having discussed flexibility with regards to equation of state decided on the future structure of the program. Using various structs and unions fprops now has a skeleton capable of supporting several possible equations.

Still to do in this area: Actually implement other EOSs (peng-robinson first), Refactor FPROPS to fit with new way of doing things.

'''24th June 2011'''

Switched to Mac OS X for development, switched to the Xcode IDE for editing, hopefully the overheads in learning the new system will be worth it. Spoke to John about support for multiple equations of state, created a couple of files ready to start experimenting.

'''20th June 2011'''

All fluid files converted from source to XML, parser demonstrated to work for every file tried so far. Further features (multiple correlations from multiple sources etc.) should be relatively easy to implement now. Acquired a copy of Sandler "Chemical and Engineering Thermodynamics" which will be helpful in sorting out implementations of the cubic equations of state.

'''17 June 2011'''

Finished writing an xml parser and translating c data files to xml .fluid files. readFluidFile() from parser.c will now load data at run time. There's still a few features to be implemented here but it's up and running now.

'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/xml/hydrogen.fluid?view=markup hydrogen.fluid]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/parserMkII.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[Redlich Kwong EOS in FPROPS|Redlich Kwong]] & [[PengRobinson EOS in FPROPS|Peng Robinson]] cubic EOSs. See {{srcbranch|richard|models/johnpye/fprops/pengrob.c}},
{{srcbranch|richard|models/johnpye/fprops/pengrob.h}},
{{srcbranch|richard|models/johnpye/fprops/redkw.c}} and
{{srcbranch|richard|models/johnpye/fprops/redkw.h}} for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

One of the main challenges here is to write functions which can take any correlation data struct as an input, decide which correlation to use, and return the desired value. After some consultation with John, we've decided on a struct containing all of the data and pointers to the various functions. A union is used to enable different types of data to be passed to functions with the same arguments.
<source lang="c">
/** Enumerate EOS correlations
*/
enum eos{
pengrob,
redkw,
helmholtz,
mbwr //etc.
};

/** Union for equation of state data
*/
typedef union eos_tag{
HelmholtzData* helmholtzData;
CubicData* cubicData;
//etc...
} EosData;

/** Definition of a fluid property function pointer
*/
typedef double (*propFnPtr)(double,double,const EosData*);

/**
Structure pointing to the necessary data and functions to calculate
fluid properties.
*/
typedef struct pureFluid{
enum eos type;
IdealData *idealData;
EosData *eosData;
//Pointers to departure functions
propFnPtr p_fn;
propFnPtr u_fn;
propFnPtr h_fn;
propFnPtr s_fn;
propFnPtr a_fn;
propFnPtr cv_fn;
propFnPtr cp_fn;
propFnPtr w_fn;
propFnPtr g_fn;
} pureFluid;
</source>

The structure can be created as follows, and then the function pointers can simply be followed to the correct function.
<source lang="c">
EosData eosData={.cubicData=&cData};
pureFluid fluidData={
pengrob,
&iData,
&eosData,
//Pointers to departure functions
pengrob_p,
pengrob_u_depart,
pengrob_h_depart,
pengrob_s_depart,
pengrob_a_depart,
pengrob_cv,
pengrob_cp,
pengrob_w,
pengrob_g_depart
};

double p=fluidData.p_fn(T,rho,fluidData.eosData);
</source>
[[Category:GSOC2011]]

User:RichardTowers

2011-08-04T15:16:01Z

RichardTowers: /* Progress reports */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

Browse code: {{srcbranchdir|richard|models/johnpye/fprops}}
== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* [[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''4th August 2011'''

Helmholtz calculations now work with the new data structures. All fluids and tests have been updated and work (except for ethanol and isohexane who's tests report small and large errors respectively). Peng-Robinson appears to give almost completely different values to helmholtz even for pressure which should be trivial. This is '''not''' expected, and the cause needs investigating before we can move into more FPROPS-esque support for ideal and saturation calculations. John emailed with an updated list of goals which are as follows:

'''25th July 2011'''

Peng-Robinson EOS now successfully calculates <math>p(V,T)</math>, <math>V(p,T)</math> and <math>\Delta h(V,T)</math>, <math>\Delta s(V,T)</math>. Redlich-Kwong EOS also works, but has additional '''untested''' support for a,u,g departure functions. Once the two new EOSs are integrated with current ideal and saturation calculations then we'll have two new EOSs.

'''15th July 2011'''

Most of the way to a working implementation of the Peng-Robinson equation of state, there are still some issues to be resolved with respect to ideal properties and internal representation of data.

XML data file structure decided upon and a human readable transformation written, still require an input form to create these files. Will also need to modify cToXML to create files for the existing fluids (Note: Will have to be careful with rounding).

'''4th July 2011'''

Having discussed flexibility with regards to equation of state decided on the future structure of the program. Using various structs and unions fprops now has a skeleton capable of supporting several possible equations.

Still to do in this area: Actually implement other EOSs (peng-robinson first), Refactor FPROPS to fit with new way of doing things.

'''24th June 2011'''

Switched to Mac OS X for development, switched to the Xcode IDE for editing, hopefully the overheads in learning the new system will be worth it. Spoke to John about support for multiple equations of state, created a couple of files ready to start experimenting.

'''20th June 2011'''

All fluid files converted from source to XML, parser demonstrated to work for every file tried so far. Further features (multiple correlations from multiple sources etc.) should be relatively easy to implement now. Acquired a copy of Sandler "Chemical and Engineering Thermodynamics" which will be helpful in sorting out implementations of the cubic equations of state.

'''17 June 2011'''

Finished writing an xml parser and translating c data files to xml .fluid files. readFluidFile() from parser.c will now load data at run time. There's still a few features to be implemented here but it's up and running now.

'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/xml/hydrogen.fluid?view=markup hydrogen.fluid]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/parserMkII.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[Redlich Kwong EOS in FPROPS|Redlich Kwong]] & [[PengRobinson EOS in FPROPS|Peng Robinson]] cubic EOSs. See {{srcbranch|richard|models/johnpye/fprops/pengrob.c}},
{{srcbranch|richard|models/johnpye/fprops/pengrob.h}},
{{srcbranch|richard|models/johnpye/fprops/redkw.c}} and
{{srcbranch|richard|models/johnpye/fprops/redkw.h}} for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

One of the main challenges here is to write functions which can take any correlation data struct as an input, decide which correlation to use, and return the desired value. After some consultation with John, we've decided on a struct containing all of the data and pointers to the various functions. A union is used to enable different types of data to be passed to functions with the same arguments.
<source lang="c">
/** Enumerate EOS correlations
*/
enum eos{
pengrob,
redkw,
helmholtz,
mbwr //etc.
};

/** Union for equation of state data
*/
typedef union eos_tag{
HelmholtzData* helmholtzData;
CubicData* cubicData;
//etc...
} EosData;

/** Definition of a fluid property function pointer
*/
typedef double (*propFnPtr)(double,double,const EosData*);

/**
Structure pointing to the necessary data and functions to calculate
fluid properties.
*/
typedef struct pureFluid{
enum eos type;
IdealData *idealData;
EosData *eosData;
//Pointers to departure functions
propFnPtr p_fn;
propFnPtr u_fn;
propFnPtr h_fn;
propFnPtr s_fn;
propFnPtr a_fn;
propFnPtr cv_fn;
propFnPtr cp_fn;
propFnPtr w_fn;
propFnPtr g_fn;
} pureFluid;
</source>

The structure can be created as follows, and then the function pointers can simply be followed to the correct function.
<source lang="c">
EosData eosData={.cubicData=&cData};
pureFluid fluidData={
pengrob,
&iData,
&eosData,
//Pointers to departure functions
pengrob_p,
pengrob_u_depart,
pengrob_h_depart,
pengrob_s_depart,
pengrob_a_depart,
pengrob_cv,
pengrob_cp,
pengrob_w,
pengrob_g_depart
};

double p=fluidData.p_fn(T,rho,fluidData.eosData);
</source>
[[Category:GSOC2011]]

User:RichardTowers

2011-07-26T08:59:40Z

RichardTowers: /* Progress reports */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

Browse code: {{srcbranchdir|richard|models/johnpye/fprops}}
== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* [[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''25th July 2011'''

Peng-Robinson EOS now successfully calculates <math>p(V,T)</math>, <math>V(p,T)</math> and <math>\Delta h(V,T)</math>, <math>\Delta s(V,T)</math>. Redlich-Kwong EOS also works, but has additional '''untested''' support for a,u,g departure functions. Once the two new EOSs are integrated with current ideal and saturation calculations then we'll have two new EOSs.

'''15th July 2011'''

Most of the way to a working implementation of the Peng-Robinson equation of state, there are still some issues to be resolved with respect to ideal properties and internal representation of data.

XML data file structure decided upon and a human readable transformation written, still require an input form to create these files. Will also need to modify cToXML to create files for the existing fluids (Note: Will have to be careful with rounding).

'''4th July 2011'''

Having discussed flexibility with regards to equation of state decided on the future structure of the program. Using various structs and unions fprops now has a skeleton capable of supporting several possible equations.

Still to do in this area: Actually implement other EOSs (peng-robinson first), Refactor FPROPS to fit with new way of doing things.

'''24th June 2011'''

Switched to Mac OS X for development, switched to the Xcode IDE for editing, hopefully the overheads in learning the new system will be worth it. Spoke to John about support for multiple equations of state, created a couple of files ready to start experimenting.

'''20th June 2011'''

All fluid files converted from source to XML, parser demonstrated to work for every file tried so far. Further features (multiple correlations from multiple sources etc.) should be relatively easy to implement now. Acquired a copy of Sandler "Chemical and Engineering Thermodynamics" which will be helpful in sorting out implementations of the cubic equations of state.

'''17 June 2011'''

Finished writing an xml parser and translating c data files to xml .fluid files. readFluidFile() from parser.c will now load data at run time. There's still a few features to be implemented here but it's up and running now.

'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/xml/hydrogen.fluid?view=markup hydrogen.fluid]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/parserMkII.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[Redlich Kwong EOS in FPROPS|Redlich Kwong]] & [[PengRobinson EOS in FPROPS|Peng Robinson]] cubic EOSs. See {{srcbranch|richard|models/johnpye/fprops/pengrob.c}},
{{srcbranch|richard|models/johnpye/fprops/pengrob.h}},
{{srcbranch|richard|models/johnpye/fprops/redkw.c}} and
{{srcbranch|richard|models/johnpye/fprops/redkw.h}} for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

One of the main challenges here is to write functions which can take any correlation data struct as an input, decide which correlation to use, and return the desired value. After some consultation with John, we've decided on a struct containing all of the data and pointers to the various functions. A union is used to enable different types of data to be passed to functions with the same arguments.
<source lang="c">
/** Enumerate EOS correlations
*/
enum eos{
pengrob,
redkw,
helmholtz,
mbwr //etc.
};

/** Union for equation of state data
*/
typedef union eos_tag{
HelmholtzData* helmholtzData;
CubicData* cubicData;
//etc...
} EosData;

/** Definition of a fluid property function pointer
*/
typedef double (*propFnPtr)(double,double,const EosData*);

/**
Structure pointing to the necessary data and functions to calculate
fluid properties.
*/
typedef struct pureFluid{
enum eos type;
IdealData *idealData;
EosData *eosData;
//Pointers to departure functions
propFnPtr p_fn;
propFnPtr u_fn;
propFnPtr h_fn;
propFnPtr s_fn;
propFnPtr a_fn;
propFnPtr cv_fn;
propFnPtr cp_fn;
propFnPtr w_fn;
propFnPtr g_fn;
} pureFluid;
</source>

The structure can be created as follows, and then the function pointers can simply be followed to the correct function.
<source lang="c">
EosData eosData={.cubicData=&cData};
pureFluid fluidData={
pengrob,
&iData,
&eosData,
//Pointers to departure functions
pengrob_p,
pengrob_u_depart,
pengrob_h_depart,
pengrob_s_depart,
pengrob_a_depart,
pengrob_cv,
pengrob_cp,
pengrob_w,
pengrob_g_depart
};

double p=fluidData.p_fn(T,rho,fluidData.eosData);
</source>
[[Category:GSOC2011]]

PengRobinson EOS in FPROPS

2011-07-22T15:00:05Z

RichardTowers: /* Overview - fixed elusive mistake which has been bugging me for HOURS.*/

PengRobinson EOS in FPROPS

2011-07-17T20:32:21Z

RichardTowers: /* Departure Functions */

User:RichardTowers

2011-07-15T16:36:44Z

RichardTowers: /* Progress reports */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

Browse code: {{srcbranchdir|richard|models/johnpye/fprops}}
== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* [[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''15th July 2011'''

Most of the way to a working implementation of the Peng-Robinson equation of state, there are still some issues to be resolved with respect to ideal properties and internal representation of data.

XML data file structure decided upon and a human readable transformation written, still require an input form to create these files. Will also need to modify cToXML to create files for the existing fluids (Note: Will have to be careful with rounding).

'''4th July 2011'''

Having discussed flexibility with regards to equation of state decided on the future structure of the program. Using various structs and unions fprops now has a skeleton capable of supporting several possible equations.

Still to do in this area: Actually implement other EOSs (peng-robinson first), Refactor FPROPS to fit with new way of doing things.

'''24th June 2011'''

Switched to Mac OS X for development, switched to the Xcode IDE for editing, hopefully the overheads in learning the new system will be worth it. Spoke to John about support for multiple equations of state, created a couple of files ready to start experimenting.

'''20th June 2011'''

All fluid files converted from source to XML, parser demonstrated to work for every file tried so far. Further features (multiple correlations from multiple sources etc.) should be relatively easy to implement now. Acquired a copy of Sandler "Chemical and Engineering Thermodynamics" which will be helpful in sorting out implementations of the cubic equations of state.

'''17 June 2011'''

Finished writing an xml parser and translating c data files to xml .fluid files. readFluidFile() from parser.c will now load data at run time. There's still a few features to be implemented here but it's up and running now.

'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/xml/hydrogen.fluid?view=markup hydrogen.fluid]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/parserMkII.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[Redlich Kwong EOS in FPROPS|Redlich Kwong]] & [[PengRobinson EOS in FPROPS|Peng Robinson]] cubic EOSs. See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup redkw.c], [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup redkw.h],
[http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

One of the main challenges here is to write functions which can take any correlation data struct as an input, decide which correlation to use, and return the desired value. After some consultation with John, we've decided on a struct containing all of the data and pointers to the various functions. A union is used to enable different types of data to be passed to functions with the same arguments.
<source lang="c">
/** Enumerate EOS correlations
*/
enum eos{
pengrob,
redkw,
helmholtz,
mbwr //etc.
};

/** Union for equation of state data
*/
typedef union eos_tag{
HelmholtzData* helmholtzData;
CubicData* cubicData;
//etc...
} EosData;

/** Definition of a fluid property function pointer
*/
typedef double (*propFnPtr)(double,double,const EosData*);

/**
Structure pointing to the necessary data and functions to calculate
fluid properties.
*/
typedef struct pureFluid{
enum eos type;
IdealData *idealData;
EosData *eosData;
//Pointers to departure functions
propFnPtr p_fn;
propFnPtr u_fn;
propFnPtr h_fn;
propFnPtr s_fn;
propFnPtr a_fn;
propFnPtr cv_fn;
propFnPtr cp_fn;
propFnPtr w_fn;
propFnPtr g_fn;
} pureFluid;
</source>

The structure can be created as follows, and then the function pointers can simply be followed to the correct function.
<source lang="c">
EosData eosData={.cubicData=&cData};
pureFluid fluidData={
pengrob,
&iData,
&eosData,
//Pointers to departure functions
pengrob_p,
pengrob_u_depart,
pengrob_h_depart,
pengrob_s_depart,
pengrob_a_depart,
pengrob_cv,
pengrob_cp,
pengrob_w,
pengrob_g_depart
};

double p=fluidData.p_fn(T,rho,fluidData.eosData);
</source>
[[Category:GSOC2011]]

PengRobinson EOS in FPROPS

2011-07-14T13:43:33Z

RichardTowers: /* Departure Functions */

PengRobinson EOS in FPROPS

2011-07-14T12:00:22Z

RichardTowers: /* Departure Functions */

PengRobinson EOS in FPROPS

2011-07-14T10:50:06Z

RichardTowers: /* Overview - Rewritten to get my head straight...*/

User:RichardTowers

2011-07-09T21:50:03Z

RichardTowers: /* Goals */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

Browse code: {{srcbranchdir|richard|models/johnpye/fprops}}
== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* [[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''4th July 2011'''

Having discussed flexibility with regards to equation of state decided on the future structure of the program. Using various structs and unions fprops now has a skeleton capable of supporting several possible equations.

Still to do in this area: Actually implement other EOSs (peng-robinson first), Refactor FPROPS to fit with new way of doing things.

'''24th June 2011'''

Switched to Mac OS X for development, switched to the Xcode IDE for editing, hopefully the overheads in learning the new system will be worth it. Spoke to John about support for multiple equations of state, created a couple of files ready to start experimenting.

'''20th June 2011'''

All fluid files converted from source to XML, parser demonstrated to work for every file tried so far. Further features (multiple correlations from multiple sources etc.) should be relatively easy to implement now. Acquired a copy of Sandler "Chemical and Engineering Thermodynamics" which will be helpful in sorting out implementations of the cubic equations of state.

'''17 June 2011'''

Finished writing an xml parser and translating c data files to xml .fluid files. readFluidFile() from parser.c will now load data at run time. There's still a few features to be implemented here but it's up and running now.

'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/xml/hydrogen.fluid?view=markup hydrogen.fluid]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/parserMkII.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[Redlich Kwong EOS in FPROPS|Redlich Kwong]] & [[PengRobinson EOS in FPROPS|Peng Robinson]] cubic EOSs. See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup redkw.c], [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup redkw.h],
[http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

One of the main challenges here is to write functions which can take any correlation data struct as an input, decide which correlation to use, and return the desired value. After some consultation with John, we've decided on a struct containing all of the data and pointers to the various functions. A union is used to enable different types of data to be passed to functions with the same arguments.
<source lang="c">
/** Enumerate EOS correlations
*/
enum eos{
pengrob,
redkw,
helmholtz,
mbwr //etc.
};

/** Union for equation of state data
*/
typedef union eos_tag{
HelmholtzData* helmholtzData;
CubicData* cubicData;
//etc...
} EosData;

/** Definition of a fluid property function pointer
*/
typedef double (*propFnPtr)(double,double,const EosData*);

/**
Structure pointing to the necessary data and functions to calculate
fluid properties.
*/
typedef struct pureFluid{
enum eos type;
IdealData *idealData;
EosData *eosData;
//Pointers to departure functions
propFnPtr p_fn;
propFnPtr u_fn;
propFnPtr h_fn;
propFnPtr s_fn;
propFnPtr a_fn;
propFnPtr cv_fn;
propFnPtr cp_fn;
propFnPtr w_fn;
propFnPtr g_fn;
} pureFluid;
</source>

The structure can be created as follows, and then the function pointers can simply be followed to the correct function.
<source lang="c">
EosData eosData={.cubicData=&cData};
pureFluid fluidData={
pengrob,
&iData,
&eosData,
//Pointers to departure functions
pengrob_p,
pengrob_u_depart,
pengrob_h_depart,
pengrob_s_depart,
pengrob_a_depart,
pengrob_cv,
pengrob_cp,
pengrob_w,
pengrob_g_depart
};

double p=fluidData.p_fn(T,rho,fluidData.eosData);
</source>
[[Category:GSOC2011]]

Porting to Mac

2011-07-07T21:56:48Z

RichardTowers: /* Building Native GTK+ - There are binaries now!*/

ASCEND now '''runs successfully on Mac''' without problems. The remaining work is to package ASCEND as an installer or as an 'app', and to fix it so that it connects with Apple Events for opening files from the Finder, etc -- see below for details.
{{task}}

== Installing the necessary tools ==

You should install the following tools in order to be able to build ASCEND on Mac:

* '''XCode''' from your OS X CD.
* '''gfortran'''. Use gfortran-macosx-x86.dmg from http://gcc.gnu.org/wiki/GFortranBinaries
* '''scons''' by typing 'sudo easy_install scons'
* '''swig'''. We have version 1.3.31, which comes with Xcode (confirmed as of Xcode 4.02)
* '''subversion''' (see [[VersionManagement|here]] or try the [http://www.open.collab.net/downloads/community/OpenCollabNet OpenCollabNet version])

== Building ==

When the above tools are installed and you have obtained the source code either from a file release or from our [[VersionManagement|code repository]], now you should be able to build ASCEND. Try just running

<source lang="sh">scons</source>

There should be some output to tell you if you're missing any important components. Otherwise, you should then be able to run

<source lang="sh">./test.py TestSolver.testlog10</source>

and you should see a message saying 'OK'. At this stage you have a complete working copy of ASCEND, possibly minus some of the userful [[solvers]] like [[IPOPT]], [[IDA]], [[CONOPT]]. The other important thing that you're missing is the GTK+ GUI library that allows ASCEND to present its user interface.

== Building Native GTK+ ==
=== The Easy Way ===

The good people who develop PyGTK have produced a pre-compiled package: [http://afb.users.sourceforge.net/zero-install/PyGTK.pkg PyGTK.pkg].

: As of July 2011 this is in testing, it worked perfectly for me though. [[User:RichardTowers|RichardTowers]] 21:56, 7 July 2011 (UTC)

=== The Hard Way ===

ASCEND uses GTK+ for its GUI. This is a cross-platform GUI library that works primarily on Linux but is also supported on Windows and Mac OS X. For Mac, it is currently necessary to build it from source, following the [http://sourceforge.net/apps/trac/gtk-osx/wiki/Build instructions from the GTK-OSX project].

Steps are something like this:

* Make sure you have Xcode, subversion and git installed, as outlined at http://sourceforge.net/apps/trac/gtk-osx/wiki/Build
* Download the script [https://raw.github.com/jralls/gtk-osx-build/master/gtk-osx-build-setup.sh] and run it using '<tt>sh gtk-osx-build-setup.sh</tt>' (no quotes).
* Edit the resulting <tt>~/.jhbuildrc-custom</tt> file, adding '<tt>build_policy = "updated-deps"</tt>' as a line at the end of the file (no single quotes).
* Set up an alias that will run <tt>jhbuild</tt> in a stripped down environment that does not contain any reference to the Fink (/sw/...) or MacPorts (?) directories (if you have them): A good option is to set
:<pre>alias jhbuild="PATH=/opt/subversion/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin:~/gtk/inst ~/.local/bin/jhbuild"</pre>
* According to the [http://sourceforge.net/apps/trac/gtk-osx/wiki/Build description on Sourceforge], build PyGTK as follows:
** <tt>jhbuild bootstrap</tt>
** <tt>jhbuild build meta-gtk-osx-bootstrap</tt>
** <tt>jhbuild build meta-gtk-osx-core</tt>
** <tt>jhbuild pygtk</tt> (or [http://sourceforge.net/apps/trac/gtk-osx/wiki/PyGtk should it be]: <tt>meta-gtk-osx-python</tt> ?)

You can now test that PyGTK is working by running <tt>python</tt> and checking that <tt>import gtk</tt> doesn't cause errors.

If that's working, you should be able to use your working copy of ASCEND (as above) to run <tt>pygtk/ascdev</tt>. This should open ASCEND, but you may have to command-tab to the correct window, as it won't pop to the front automatically.

Here's a screenshot of ASCEND on Native GTK-Quartz on OS X!

[[Image:ASCENDnativeOSX.png|thumb|300px|none|Screenshot of the PyGTK GUI running on Mac OSX with GTK-OSX (Quartz/Native GTK)]]

'''Note''': currently, the ASCEND GUI on Mac still behaves much the same as it would on Windows or Linux; we haven't yet 'mackified' the keyboard shortcuts and menu layout. This will be using the 'ige-mac-integration' library that's also provided by the GTK-OSX project.

Note that allegedly it is also possible to build native GTK using macports, but we haven't yet tried that.

== Building the Tcl/Tk GUI ==

No work yet to determine what will be required to the Tcl/Tk GUI running on Mac.

It ''may'' be fairly straightforward to get this GUI running, possibly using these binaries for Tcl/Tk:

* http://www.categorifiedcoder.info/tcltk/

== Preparing for distribution ==

''The following part is still under development.''

Once GTK is build using jhbuild above, we need to re-package ASCEND in the form of a 'normal' Mac OS X application. To do this,

<source lang="a4c">cd ~/ascend
python scons/installgtk.py
scons install INSTALL_PREFIX=~/ascinst</source>

Those steps will first copy GTK and associated files into <tt>dist/PyGTK.bundle</tt>. Next, they will copy all the ASCEND files as well as PyGTK.bundle into ~/ascinst/ASCEND.app. Other files will be added to the ~/ascint folder, in preparation for making a .dmg disk image that will be suitable for distribution.

Currently, we are still working out some final bugs with the creation of the PyGTK.bundle, so this final step doesn't entirely work.

== Development notes ==

=== Packaging and distribution ===

It's recommended for most Mac applications that everything be distributed as an Application Bundle that just be dragged by the user into their Applications folder. This is certainly possible with ASCEND, but a problem is that the ASCEND Model Library is something that we would like users to see and interact with. We would like users to be able to see these folders and their contents easily using the Finder. Nesting the files within an Application bundle makes this rather difficult.

One option would be for the ASCEND application to unpack its model library to ~/Library/Application Support/ASCEND when the program is first run. This would require Python scripting, and would not be compatible with a shared installation of the Tcl/Tk GUI on the same system.

Another option would be to install the model library in /Library/Application Support/ASCEND/Models. This seems to be the right way forward, but it means that ASCEND can no longer just be dragged to the Applications folder to be installed. Instead, it would need an Installer to place the necessary files on the user's system. That's quite desirable, though, because such an installer could also check that the user has the correct versions of Python, GTK and PyGTK already installed on the system, and could even possibly download and install them first if required.

It's worth noting that Mac editors like TextEdit can't peer into Application Bundles, but non-Mac editors like gedit can do so... they don't impose the same restriction on entering inside such bundles.

As a first attempt for getting everything running, it seems wise to take the simple application bundle approach.

We're not currently proposing to provide the Tcl/Tk GUI for Mac. This is a whole separate packaging problem.

We're not currently proposing to package libascend as a Framework for Mac, although that is an option, and would be appropriate if attempting to provide both Tcl/Tk and PyGTK GUIs on the same machine, and to make it easier for users to develop their own solvers, etc, on that platform.

The general opinion on GTK is that we should include it within out Application Bundle. From the linux point of view, this is terribly inefficient, but such things are standard practise on Mac, and we should respect that in the first instance.

The alternative of providing ASCEND to the Mac community as a Fink package was considered, however, according to Fink developers, the current 'stable' repository for Fink is very stagnant, so we are unlikely to be able to use that as a means for distribution.

If we want to distribute ASCEND as a multi-component thing (libascend framework, Tcl/Tk GUI, PyGTK, model library all separate) then we would need to use the Apple tool, ''PackageMaker'', which allows developers to produce their own .pkg installers, apparently<ref>http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html</ref>. It is preferable to distribute a simple Application Bundle within a .dmg Disk Image.

=== Creating ASCEND.app ===

To create the ASCEND application bundle

* scons -j2 install INSTALL_PREFIX=~/ascinst
* The bundle will appear as ~/ascinst/ASCEND.app
* TODO: add necessary GTK files to the .app!
* follow instructions below to turn it into a redistributable disk image

The file {{src|mac/Info.plist}} contains all the key-value stuff describing the application. We had to make changes to {{src|pygtk/ascend.in}} to accommodate the particularities of the Mac platform, too.

=== Creating a Disk Image (ASCEND-0.9.X.dmg) ===

Some instructions are here: http://www.wikihow.com/Make-a-DMG-File-on-a-Mac

In summary:

* use the Applications/Utilities/Disk Utility application
* create a new image large enough for your needs
* mount and open the image
* from the Terminal, run scons -j2 install INSTALL_PREFIX=(location of your disk image folder)
* set the folder background image to ~/ascend/mac/folder-background.png
* arrange the files so that they look OK, the folder-background arrow should point from the ASCEND.app to the Applications folder alias.
* return to the disk image program
* click 'convert' and convert to a compressed image (OK to overwrite)
* all done, you can double-click the image file now, and it should mount and appear as you wanted it.

=== Finding all the GTK files ===

To create a safely porting ASCEND.app, we need to embed all of GTK into the application bundle. The above application won't be complete until we achieve that.

Looks like some Python packages called [http://docs.python.org/library/modulefinder.html modulefinder] (built-in to Python) or [http://pypi.python.org/pypi/modulegraph/ modulegraph] (external) may be able to help with locating all the necessary files for satisfying Python 'import' dependencies.

Then, [http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/otool.1.html otool] ('otool -L') can be used to find shared library dependencies.

There are also some other files such as bitmaps, 'locale' files, and maybe others that will be required for correct running of GTK; these also need to be bundled.

The tool [http://sourceforge.net/apps/trac/gtk-osx/wiki/Bundle ige-mac-bundler] seems to provide some degree of automation for this process, although it seems to be more oriented for C application than Python. We have some [[Porting_to_Mac/ige-mac-bundler|notes on how it works]].

The shell-script gimpguts.sh, available from GIMPskel.zip on [http://gimp-app.sourceforge.net/ this page] also contains some code for pulling in the necessary bits of GTK for packaging.

Our solution is a Python script that makes calls to 'otool' and 'modulefinder'. We hope to be able to incorporate this script into our SCons build scripts as a 'tool', but at the moment, {{src|scons/installgtk.py}} is standalone. This is still under development.

Most Mac libraries by default are hard-wired with absolute dependency paths as [http://blogs.sun.com/dipol/entry/dynamic_libraries_rpath_and_mac described by Joe Di Pol]. The solution seems to be to post-process the shared libraries after they have been copied, using 'install_name_tool'.

=== Problems with non-english Systems ===

You need to set your System to english - it's not about your system user interface language and not about your keyboard, it about the Formats.

Go to
System Preferences -> Interantional -> Formats

select english US and reboot your system.

If you do not take this step, ascend will ignore all decimal places.
PI will be 3.0000 instead of 3.1415, numbers like 0.12345 will be 0.00000 possibly causing "Division by Zero" Errors.

=== Problems With Matplotlib ===

[http://matplotlib.sourceforge.net/ Matplotlib] is used for all plotting by the PyGTK GUI, and Matplotlib in turn depends on [http://numpy.scipy.org/ NumPy]. NumPy doesn't work correctly with Apple's System Python, so you have to install MacPython to use the standard binary releases of Matplotlib and NumPy. Alternatively, it's possible to go back and download older versions of NumPy that ''do'' run on Apple's Python, but you'll presumably be losing some functionaly as a result.

The conclusion from all this is that it might be advisable for ASCEND on the Mac to be linked against MacPython, and for a runtime check to be made to ensure that the correct version is in place.

=== Connecting to Apple Events ===

Currently, GTK on Mac has no support for receiving or sending Apple Events. This is a problem, because Mac OS X attempts to communicate using Apple Events when a file is to be opened. If the app is not listening for events, then nothing will happen.

However, there seems to be a workaround for the case of Python scripts: [http://appscript.sourceforge.net appscript], which contains a module called [http://appscript.sourceforge.net/py-appscript/doc/aem-manual/05_targettingapplications.html py-aem]. It may be possible to incorporate this into ASCEND as a way for processing such events. There may be other similar modules, possible. Also, PyObjC may provide another way of creating event listeners. These modules are included by default with [http://www.python.org/download/mac/ MacPython].

According to GTK-OSX, there has not yet been any attempt to incorporate this stuff into ige-mac-integration, although it was agreed that it would be desirable to integrate it there (to benefit also C-based GTK applications ported to Mac).

An alternative approach might be to write a very small Carbon/Cocoa application that could do the event listening, and pass the events on to the main application.

=== Alternative approach: Homebrew? ===

A new method<ref>http://blog.abhiomkar.in/2010/01/02/macports-to-homebrew-new-packaging-system-for-mac-os-x/</ref> of obtaining GTK, SWIG, SCons and other tools is via [http://github.com/mxcl/homebrew Homebrew].

An initial check of Homebrew shows that although it provides GTK+, at this stage it only provides the X11 version of GTK+, which does not help with the task of creating native GTK+ ASCEND as desired here. Also, the 'gtk-demo' compiled by Homebrew seems to segfault, not sure what the reason for that was.

== References ==
<references/>

[[Category:Development]]
[[Category:Mac_OS_X]]

Porting to Mac

2011-07-07T10:33:40Z

RichardTowers: /* Building Native GTK+ - Fixed outdated file link*/

ASCEND now '''runs successfully on Mac''' without problems. The remaining work is to package ASCEND as an installer or as an 'app', and to fix it so that it connects with Apple Events for opening files from the Finder, etc -- see below for details.
{{task}}

== Installing the necessary tools ==

You should install the following tools in order to be able to build ASCEND on Mac:

* '''XCode''' from your OS X CD.
* '''gfortran'''. Use gfortran-macosx-x86.dmg from http://gcc.gnu.org/wiki/GFortranBinaries
* '''scons''' by typing 'sudo easy_install scons'
* '''swig'''. We have version 1.3.31, which comes with Xcode (confirmed as of Xcode 4.02)
* '''subversion''' (see [[VersionManagement|here]] or try the [http://www.open.collab.net/downloads/community/OpenCollabNet OpenCollabNet version])

== Building ==

When the above tools are installed and you have obtained the source code either from a file release or from our [[VersionManagement|code repository]], now you should be able to build ASCEND. Try just running

<source lang="sh">scons</source>

There should be some output to tell you if you're missing any important components. Otherwise, you should then be able to run

<source lang="sh">./test.py TestSolver.testlog10</source>

and you should see a message saying 'OK'. At this stage you have a complete working copy of ASCEND, possibly minus some of the userful [[solvers]] like [[IPOPT]], [[IDA]], [[CONOPT]]. The other important thing that you're missing is the GTK+ GUI library that allows ASCEND to present its user interface.

== Building Native GTK+ ==

ASCEND uses GTK+ for its GUI. This is a cross-platform GUI library that works primarily on Linux but is also supported on Windows and Mac OS X. For Mac, it is currently necessary to build it from source, following the [http://sourceforge.net/apps/trac/gtk-osx/wiki/Build instructions from the GTK-OSX project].

Steps are something like this:

* Make sure you have Xcode, subversion and git installed, as outlined at http://sourceforge.net/apps/trac/gtk-osx/wiki/Build
* Download the script [https://raw.github.com/jralls/gtk-osx-build/master/gtk-osx-build-setup.sh] and run it using '<tt>sh gtk-osx-build-setup.sh</tt>' (no quotes).
* Edit the resulting <tt>~/.jhbuildrc-custom</tt> file, adding '<tt>build_policy = "updated-deps"</tt>' as a line at the end of the file (no single quotes).
* Set up an alias that will run <tt>jhbuild</tt> in a stripped down environment that does not contain any reference to the Fink (/sw/...) or MacPorts (?) directories (if you have them): A good option is to set
:<pre>alias jhbuild="PATH=/opt/subversion/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin:~/gtk/inst ~/.local/bin/jhbuild"</pre>
* According to the [http://sourceforge.net/apps/trac/gtk-osx/wiki/Build description on Sourceforge], build PyGTK as follows:
** <tt>jhbuild bootstrap</tt>
** <tt>jhbuild build meta-gtk-osx-bootstrap</tt>
** <tt>jhbuild build meta-gtk-osx-core</tt>
** <tt>jhbuild pygtk</tt> (or [http://sourceforge.net/apps/trac/gtk-osx/wiki/PyGtk should it be]: <tt>meta-gtk-osx-python</tt> ?)

You can now test that PyGTK is working by running <tt>python</tt> and checking that <tt>import gtk</tt> doesn't cause errors.

If that's working, you should be able to use your working copy of ASCEND (as above) to run <tt>pygtk/ascdev</tt>. This should open ASCEND, but you may have to command-tab to the correct window, as it won't pop to the front automatically.

Here's a screenshot of ASCEND on Native GTK-Quartz on OS X!

[[Image:ASCENDnativeOSX.png|thumb|300px|none|Screenshot of the PyGTK GUI running on Mac OSX with GTK-OSX (Quartz/Native GTK)]]

'''Note''': currently, the ASCEND GUI on Mac still behaves much the same as it would on Windows or Linux; we haven't yet 'mackified' the keyboard shortcuts and menu layout. This will be using the 'ige-mac-integration' library that's also provided by the GTK-OSX project.

Note that allegedly it is also possible to build native GTK using macports, but we haven't yet tried that.

== Building the Tcl/Tk GUI ==

No work yet to determine what will be required to the Tcl/Tk GUI running on Mac.

It ''may'' be fairly straightforward to get this GUI running, possibly using these binaries for Tcl/Tk:

* http://www.categorifiedcoder.info/tcltk/

== Preparing for distribution ==

''The following part is still under development.''

Once GTK is build using jhbuild above, we need to re-package ASCEND in the form of a 'normal' Mac OS X application. To do this,

<source lang="a4c">cd ~/ascend
python scons/installgtk.py
scons install INSTALL_PREFIX=~/ascinst</source>

Those steps will first copy GTK and associated files into <tt>dist/PyGTK.bundle</tt>. Next, they will copy all the ASCEND files as well as PyGTK.bundle into ~/ascinst/ASCEND.app. Other files will be added to the ~/ascint folder, in preparation for making a .dmg disk image that will be suitable for distribution.

Currently, we are still working out some final bugs with the creation of the PyGTK.bundle, so this final step doesn't entirely work.

== Development notes ==

=== Packaging and distribution ===

It's recommended for most Mac applications that everything be distributed as an Application Bundle that just be dragged by the user into their Applications folder. This is certainly possible with ASCEND, but a problem is that the ASCEND Model Library is something that we would like users to see and interact with. We would like users to be able to see these folders and their contents easily using the Finder. Nesting the files within an Application bundle makes this rather difficult.

One option would be for the ASCEND application to unpack its model library to ~/Library/Application Support/ASCEND when the program is first run. This would require Python scripting, and would not be compatible with a shared installation of the Tcl/Tk GUI on the same system.

Another option would be to install the model library in /Library/Application Support/ASCEND/Models. This seems to be the right way forward, but it means that ASCEND can no longer just be dragged to the Applications folder to be installed. Instead, it would need an Installer to place the necessary files on the user's system. That's quite desirable, though, because such an installer could also check that the user has the correct versions of Python, GTK and PyGTK already installed on the system, and could even possibly download and install them first if required.

It's worth noting that Mac editors like TextEdit can't peer into Application Bundles, but non-Mac editors like gedit can do so... they don't impose the same restriction on entering inside such bundles.

As a first attempt for getting everything running, it seems wise to take the simple application bundle approach.

We're not currently proposing to provide the Tcl/Tk GUI for Mac. This is a whole separate packaging problem.

We're not currently proposing to package libascend as a Framework for Mac, although that is an option, and would be appropriate if attempting to provide both Tcl/Tk and PyGTK GUIs on the same machine, and to make it easier for users to develop their own solvers, etc, on that platform.

The general opinion on GTK is that we should include it within out Application Bundle. From the linux point of view, this is terribly inefficient, but such things are standard practise on Mac, and we should respect that in the first instance.

The alternative of providing ASCEND to the Mac community as a Fink package was considered, however, according to Fink developers, the current 'stable' repository for Fink is very stagnant, so we are unlikely to be able to use that as a means for distribution.

If we want to distribute ASCEND as a multi-component thing (libascend framework, Tcl/Tk GUI, PyGTK, model library all separate) then we would need to use the Apple tool, ''PackageMaker'', which allows developers to produce their own .pkg installers, apparently<ref>http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html</ref>. It is preferable to distribute a simple Application Bundle within a .dmg Disk Image.

=== Creating ASCEND.app ===

To create the ASCEND application bundle

* scons -j2 install INSTALL_PREFIX=~/ascinst
* The bundle will appear as ~/ascinst/ASCEND.app
* TODO: add necessary GTK files to the .app!
* follow instructions below to turn it into a redistributable disk image

The file {{src|mac/Info.plist}} contains all the key-value stuff describing the application. We had to make changes to {{src|pygtk/ascend.in}} to accommodate the particularities of the Mac platform, too.

=== Creating a Disk Image (ASCEND-0.9.X.dmg) ===

Some instructions are here: http://www.wikihow.com/Make-a-DMG-File-on-a-Mac

In summary:

* use the Applications/Utilities/Disk Utility application
* create a new image large enough for your needs
* mount and open the image
* from the Terminal, run scons -j2 install INSTALL_PREFIX=(location of your disk image folder)
* set the folder background image to ~/ascend/mac/folder-background.png
* arrange the files so that they look OK, the folder-background arrow should point from the ASCEND.app to the Applications folder alias.
* return to the disk image program
* click 'convert' and convert to a compressed image (OK to overwrite)
* all done, you can double-click the image file now, and it should mount and appear as you wanted it.

=== Finding all the GTK files ===

To create a safely porting ASCEND.app, we need to embed all of GTK into the application bundle. The above application won't be complete until we achieve that.

Looks like some Python packages called [http://docs.python.org/library/modulefinder.html modulefinder] (built-in to Python) or [http://pypi.python.org/pypi/modulegraph/ modulegraph] (external) may be able to help with locating all the necessary files for satisfying Python 'import' dependencies.

Then, [http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/otool.1.html otool] ('otool -L') can be used to find shared library dependencies.

There are also some other files such as bitmaps, 'locale' files, and maybe others that will be required for correct running of GTK; these also need to be bundled.

The tool [http://sourceforge.net/apps/trac/gtk-osx/wiki/Bundle ige-mac-bundler] seems to provide some degree of automation for this process, although it seems to be more oriented for C application than Python. We have some [[Porting_to_Mac/ige-mac-bundler|notes on how it works]].

The shell-script gimpguts.sh, available from GIMPskel.zip on [http://gimp-app.sourceforge.net/ this page] also contains some code for pulling in the necessary bits of GTK for packaging.

Our solution is a Python script that makes calls to 'otool' and 'modulefinder'. We hope to be able to incorporate this script into our SCons build scripts as a 'tool', but at the moment, {{src|scons/installgtk.py}} is standalone. This is still under development.

Most Mac libraries by default are hard-wired with absolute dependency paths as [http://blogs.sun.com/dipol/entry/dynamic_libraries_rpath_and_mac described by Joe Di Pol]. The solution seems to be to post-process the shared libraries after they have been copied, using 'install_name_tool'.

=== Problems with non-english Systems ===

You need to set your System to english - it's not about your system user interface language and not about your keyboard, it about the Formats.

Go to
System Preferences -> Interantional -> Formats

select english US and reboot your system.

If you do not take this step, ascend will ignore all decimal places.
PI will be 3.0000 instead of 3.1415, numbers like 0.12345 will be 0.00000 possibly causing "Division by Zero" Errors.

=== Problems With Matplotlib ===

[http://matplotlib.sourceforge.net/ Matplotlib] is used for all plotting by the PyGTK GUI, and Matplotlib in turn depends on [http://numpy.scipy.org/ NumPy]. NumPy doesn't work correctly with Apple's System Python, so you have to install MacPython to use the standard binary releases of Matplotlib and NumPy. Alternatively, it's possible to go back and download older versions of NumPy that ''do'' run on Apple's Python, but you'll presumably be losing some functionaly as a result.

The conclusion from all this is that it might be advisable for ASCEND on the Mac to be linked against MacPython, and for a runtime check to be made to ensure that the correct version is in place.

=== Connecting to Apple Events ===

Currently, GTK on Mac has no support for receiving or sending Apple Events. This is a problem, because Mac OS X attempts to communicate using Apple Events when a file is to be opened. If the app is not listening for events, then nothing will happen.

However, there seems to be a workaround for the case of Python scripts: [http://appscript.sourceforge.net appscript], which contains a module called [http://appscript.sourceforge.net/py-appscript/doc/aem-manual/05_targettingapplications.html py-aem]. It may be possible to incorporate this into ASCEND as a way for processing such events. There may be other similar modules, possible. Also, PyObjC may provide another way of creating event listeners. These modules are included by default with [http://www.python.org/download/mac/ MacPython].

According to GTK-OSX, there has not yet been any attempt to incorporate this stuff into ige-mac-integration, although it was agreed that it would be desirable to integrate it there (to benefit also C-based GTK applications ported to Mac).

An alternative approach might be to write a very small Carbon/Cocoa application that could do the event listening, and pass the events on to the main application.

=== Alternative approach: Homebrew? ===

A new method<ref>http://blog.abhiomkar.in/2010/01/02/macports-to-homebrew-new-packaging-system-for-mac-os-x/</ref> of obtaining GTK, SWIG, SCons and other tools is via [http://github.com/mxcl/homebrew Homebrew].

An initial check of Homebrew shows that although it provides GTK+, at this stage it only provides the X11 version of GTK+, which does not help with the task of creating native GTK+ ASCEND as desired here. Also, the 'gtk-demo' compiled by Homebrew seems to segfault, not sure what the reason for that was.

== References ==
<references/>

[[Category:Development]]
[[Category:Mac_OS_X]]

Porting to Mac

2011-07-07T09:54:00Z

RichardTowers: /* Installing the necessary tools */

ASCEND now '''runs successfully on Mac''' without problems. The remaining work is to package ASCEND as an installer or as an 'app', and to fix it so that it connects with Apple Events for opening files from the Finder, etc -- see below for details.
{{task}}

== Installing the necessary tools ==

You should install the following tools in order to be able to build ASCEND on Mac:

* '''XCode''' from your OS X CD.
* '''gfortran'''. Use gfortran-macosx-x86.dmg from http://gcc.gnu.org/wiki/GFortranBinaries
* '''scons''' by typing 'sudo easy_install scons'
* '''swig'''. We have version 1.3.31, which comes with Xcode (confirmed as of Xcode 4.02)
* '''subversion''' (see [[VersionManagement|here]] or try the [http://www.open.collab.net/downloads/community/OpenCollabNet OpenCollabNet version])

== Building ==

When the above tools are installed and you have obtained the source code either from a file release or from our [[VersionManagement|code repository]], now you should be able to build ASCEND. Try just running

<source lang="sh">scons</source>

There should be some output to tell you if you're missing any important components. Otherwise, you should then be able to run

<source lang="sh">./test.py TestSolver.testlog10</source>

and you should see a message saying 'OK'. At this stage you have a complete working copy of ASCEND, possibly minus some of the userful [[solvers]] like [[IPOPT]], [[IDA]], [[CONOPT]]. The other important thing that you're missing is the GTK+ GUI library that allows ASCEND to present its user interface.

== Building Native GTK+ ==

ASCEND uses GTK+ for its GUI. This is a cross-platform GUI library that works primarily on Linux but is also supported on Windows and Mac OS X. For Mac, it is currently necessary to build it from source, following the [http://sourceforge.net/apps/trac/gtk-osx/wiki/Build instructions from the GTK-OSX project].

Steps are something like this:

* Make sure you have Xcode, subversion and git installed, as outlined at http://sourceforge.net/apps/trac/gtk-osx/wiki/Build
* Download the script [http://downloads.sourceforge.net/sourceforge/gtk-osx/gtk-osx-build-setup.sh gtk-osx-build-setup.sh] and run it using '<tt>sh gtk-osx-build-setup.sh</tt>' (no quotes).
* Edit the resulting <tt>~/.jhbuildrc-custom</tt> file, adding '<tt>build_policy = "updated-deps"</tt>' as a line at the end of the file (no single quotes).
* Set up an alias that will run <tt>jhbuild</tt> in a stripped down environment that does not contain any reference to the Fink (/sw/...) or MacPorts (?) directories (if you have them): A good option is to set
:<pre>alias jhbuild="PATH=/opt/subversion/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin:~/gtk/inst ~/.local/bin/jhbuild"</pre>
* According to the [http://sourceforge.net/apps/trac/gtk-osx/wiki/Build description on Sourceforge], build PyGTK as follows:
** <tt>jhbuild bootstrap</tt>
** <tt>jhbuild build meta-gtk-osx-bootstrap</tt>
** <tt>jhbuild build meta-gtk-osx-core</tt>
** <tt>jhbuild pygtk</tt> (or [http://sourceforge.net/apps/trac/gtk-osx/wiki/PyGtk should it be]: <tt>meta-gtk-osx-python</tt> ?)

You can now test that PyGTK is working by running <tt>python</tt> and checking that <tt>import gtk</tt> doesn't cause errors.

If that's working, you should be able to use your working copy of ASCEND (as above) to run <tt>pygtk/ascdev</tt>. This should open ASCEND, but you may have to command-tab to the correct window, as it won't pop to the front automatically.

Here's a screenshot of ASCEND on Native GTK-Quartz on OS X!

[[Image:ASCENDnativeOSX.png|thumb|300px|none|Screenshot of the PyGTK GUI running on Mac OSX with GTK-OSX (Quartz/Native GTK)]]

'''Note''': currently, the ASCEND GUI on Mac still behaves much the same as it would on Windows or Linux; we haven't yet 'mackified' the keyboard shortcuts and menu layout. This will be using the 'ige-mac-integration' library that's also provided by the GTK-OSX project.

Note that allegedly it is also possible to build native GTK using macports, but we haven't yet tried that.

== Building the Tcl/Tk GUI ==

No work yet to determine what will be required to the Tcl/Tk GUI running on Mac.

It ''may'' be fairly straightforward to get this GUI running, possibly using these binaries for Tcl/Tk:

* http://www.categorifiedcoder.info/tcltk/

== Preparing for distribution ==

''The following part is still under development.''

Once GTK is build using jhbuild above, we need to re-package ASCEND in the form of a 'normal' Mac OS X application. To do this,

<source lang="a4c">cd ~/ascend
python scons/installgtk.py
scons install INSTALL_PREFIX=~/ascinst</source>

Those steps will first copy GTK and associated files into <tt>dist/PyGTK.bundle</tt>. Next, they will copy all the ASCEND files as well as PyGTK.bundle into ~/ascinst/ASCEND.app. Other files will be added to the ~/ascint folder, in preparation for making a .dmg disk image that will be suitable for distribution.

Currently, we are still working out some final bugs with the creation of the PyGTK.bundle, so this final step doesn't entirely work.

== Development notes ==

=== Packaging and distribution ===

It's recommended for most Mac applications that everything be distributed as an Application Bundle that just be dragged by the user into their Applications folder. This is certainly possible with ASCEND, but a problem is that the ASCEND Model Library is something that we would like users to see and interact with. We would like users to be able to see these folders and their contents easily using the Finder. Nesting the files within an Application bundle makes this rather difficult.

One option would be for the ASCEND application to unpack its model library to ~/Library/Application Support/ASCEND when the program is first run. This would require Python scripting, and would not be compatible with a shared installation of the Tcl/Tk GUI on the same system.

Another option would be to install the model library in /Library/Application Support/ASCEND/Models. This seems to be the right way forward, but it means that ASCEND can no longer just be dragged to the Applications folder to be installed. Instead, it would need an Installer to place the necessary files on the user's system. That's quite desirable, though, because such an installer could also check that the user has the correct versions of Python, GTK and PyGTK already installed on the system, and could even possibly download and install them first if required.

It's worth noting that Mac editors like TextEdit can't peer into Application Bundles, but non-Mac editors like gedit can do so... they don't impose the same restriction on entering inside such bundles.

As a first attempt for getting everything running, it seems wise to take the simple application bundle approach.

We're not currently proposing to provide the Tcl/Tk GUI for Mac. This is a whole separate packaging problem.

We're not currently proposing to package libascend as a Framework for Mac, although that is an option, and would be appropriate if attempting to provide both Tcl/Tk and PyGTK GUIs on the same machine, and to make it easier for users to develop their own solvers, etc, on that platform.

The general opinion on GTK is that we should include it within out Application Bundle. From the linux point of view, this is terribly inefficient, but such things are standard practise on Mac, and we should respect that in the first instance.

The alternative of providing ASCEND to the Mac community as a Fink package was considered, however, according to Fink developers, the current 'stable' repository for Fink is very stagnant, so we are unlikely to be able to use that as a means for distribution.

If we want to distribute ASCEND as a multi-component thing (libascend framework, Tcl/Tk GUI, PyGTK, model library all separate) then we would need to use the Apple tool, ''PackageMaker'', which allows developers to produce their own .pkg installers, apparently<ref>http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html</ref>. It is preferable to distribute a simple Application Bundle within a .dmg Disk Image.

=== Creating ASCEND.app ===

To create the ASCEND application bundle

* scons -j2 install INSTALL_PREFIX=~/ascinst
* The bundle will appear as ~/ascinst/ASCEND.app
* TODO: add necessary GTK files to the .app!
* follow instructions below to turn it into a redistributable disk image

The file {{src|mac/Info.plist}} contains all the key-value stuff describing the application. We had to make changes to {{src|pygtk/ascend.in}} to accommodate the particularities of the Mac platform, too.

=== Creating a Disk Image (ASCEND-0.9.X.dmg) ===

Some instructions are here: http://www.wikihow.com/Make-a-DMG-File-on-a-Mac

In summary:

* use the Applications/Utilities/Disk Utility application
* create a new image large enough for your needs
* mount and open the image
* from the Terminal, run scons -j2 install INSTALL_PREFIX=(location of your disk image folder)
* set the folder background image to ~/ascend/mac/folder-background.png
* arrange the files so that they look OK, the folder-background arrow should point from the ASCEND.app to the Applications folder alias.
* return to the disk image program
* click 'convert' and convert to a compressed image (OK to overwrite)
* all done, you can double-click the image file now, and it should mount and appear as you wanted it.

=== Finding all the GTK files ===

To create a safely porting ASCEND.app, we need to embed all of GTK into the application bundle. The above application won't be complete until we achieve that.

Looks like some Python packages called [http://docs.python.org/library/modulefinder.html modulefinder] (built-in to Python) or [http://pypi.python.org/pypi/modulegraph/ modulegraph] (external) may be able to help with locating all the necessary files for satisfying Python 'import' dependencies.

Then, [http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/otool.1.html otool] ('otool -L') can be used to find shared library dependencies.

There are also some other files such as bitmaps, 'locale' files, and maybe others that will be required for correct running of GTK; these also need to be bundled.

The tool [http://sourceforge.net/apps/trac/gtk-osx/wiki/Bundle ige-mac-bundler] seems to provide some degree of automation for this process, although it seems to be more oriented for C application than Python. We have some [[Porting_to_Mac/ige-mac-bundler|notes on how it works]].

The shell-script gimpguts.sh, available from GIMPskel.zip on [http://gimp-app.sourceforge.net/ this page] also contains some code for pulling in the necessary bits of GTK for packaging.

Our solution is a Python script that makes calls to 'otool' and 'modulefinder'. We hope to be able to incorporate this script into our SCons build scripts as a 'tool', but at the moment, {{src|scons/installgtk.py}} is standalone. This is still under development.

Most Mac libraries by default are hard-wired with absolute dependency paths as [http://blogs.sun.com/dipol/entry/dynamic_libraries_rpath_and_mac described by Joe Di Pol]. The solution seems to be to post-process the shared libraries after they have been copied, using 'install_name_tool'.

=== Problems with non-english Systems ===

You need to set your System to english - it's not about your system user interface language and not about your keyboard, it about the Formats.

Go to
System Preferences -> Interantional -> Formats

select english US and reboot your system.

If you do not take this step, ascend will ignore all decimal places.
PI will be 3.0000 instead of 3.1415, numbers like 0.12345 will be 0.00000 possibly causing "Division by Zero" Errors.

=== Problems With Matplotlib ===

[http://matplotlib.sourceforge.net/ Matplotlib] is used for all plotting by the PyGTK GUI, and Matplotlib in turn depends on [http://numpy.scipy.org/ NumPy]. NumPy doesn't work correctly with Apple's System Python, so you have to install MacPython to use the standard binary releases of Matplotlib and NumPy. Alternatively, it's possible to go back and download older versions of NumPy that ''do'' run on Apple's Python, but you'll presumably be losing some functionaly as a result.

The conclusion from all this is that it might be advisable for ASCEND on the Mac to be linked against MacPython, and for a runtime check to be made to ensure that the correct version is in place.

=== Connecting to Apple Events ===

Currently, GTK on Mac has no support for receiving or sending Apple Events. This is a problem, because Mac OS X attempts to communicate using Apple Events when a file is to be opened. If the app is not listening for events, then nothing will happen.

However, there seems to be a workaround for the case of Python scripts: [http://appscript.sourceforge.net appscript], which contains a module called [http://appscript.sourceforge.net/py-appscript/doc/aem-manual/05_targettingapplications.html py-aem]. It may be possible to incorporate this into ASCEND as a way for processing such events. There may be other similar modules, possible. Also, PyObjC may provide another way of creating event listeners. These modules are included by default with [http://www.python.org/download/mac/ MacPython].

According to GTK-OSX, there has not yet been any attempt to incorporate this stuff into ige-mac-integration, although it was agreed that it would be desirable to integrate it there (to benefit also C-based GTK applications ported to Mac).

An alternative approach might be to write a very small Carbon/Cocoa application that could do the event listening, and pass the events on to the main application.

=== Alternative approach: Homebrew? ===

A new method<ref>http://blog.abhiomkar.in/2010/01/02/macports-to-homebrew-new-packaging-system-for-mac-os-x/</ref> of obtaining GTK, SWIG, SCons and other tools is via [http://github.com/mxcl/homebrew Homebrew].

An initial check of Homebrew shows that although it provides GTK+, at this stage it only provides the X11 version of GTK+, which does not help with the task of creating native GTK+ ASCEND as desired here. Also, the 'gtk-demo' compiled by Homebrew seems to segfault, not sure what the reason for that was.

== References ==
<references/>

[[Category:Development]]
[[Category:Mac_OS_X]]

Porting to Mac

2011-07-07T09:47:18Z

RichardTowers: /* Installing the necessary tools */

ASCEND now '''runs successfully on Mac''' without problems. The remaining work is to package ASCEND as an installer or as an 'app', and to fix it so that it connects with Apple Events for opening files from the Finder, etc -- see below for details.
{{task}}

== Installing the necessary tools ==

You should install the following tools in order to be able to build ASCEND on Mac:

* '''XCode''' from your OS X CD.
* '''gfortran'''. Use gfortran-macosx-x86.dmg from http://gcc.gnu.org/wiki/GFortranBinaries
* '''scons''' by typing 'easy_install scons'
* '''swig'''. We have version 1.3.31, which comes with Xcode (confirmed as of Xcode 4.02)
* '''subversion''' (see [[VersionManagement|here]] or try the [http://www.open.collab.net/downloads/community/OpenCollabNet OpenCollabNet version])

== Building ==

When the above tools are installed and you have obtained the source code either from a file release or from our [[VersionManagement|code repository]], now you should be able to build ASCEND. Try just running

<source lang="sh">scons</source>

There should be some output to tell you if you're missing any important components. Otherwise, you should then be able to run

<source lang="sh">./test.py TestSolver.testlog10</source>

and you should see a message saying 'OK'. At this stage you have a complete working copy of ASCEND, possibly minus some of the userful [[solvers]] like [[IPOPT]], [[IDA]], [[CONOPT]]. The other important thing that you're missing is the GTK+ GUI library that allows ASCEND to present its user interface.

== Building Native GTK+ ==

ASCEND uses GTK+ for its GUI. This is a cross-platform GUI library that works primarily on Linux but is also supported on Windows and Mac OS X. For Mac, it is currently necessary to build it from source, following the [http://sourceforge.net/apps/trac/gtk-osx/wiki/Build instructions from the GTK-OSX project].

Steps are something like this:

* Make sure you have Xcode, subversion and git installed, as outlined at http://sourceforge.net/apps/trac/gtk-osx/wiki/Build
* Download the script [http://downloads.sourceforge.net/sourceforge/gtk-osx/gtk-osx-build-setup.sh gtk-osx-build-setup.sh] and run it using '<tt>sh gtk-osx-build-setup.sh</tt>' (no quotes).
* Edit the resulting <tt>~/.jhbuildrc-custom</tt> file, adding '<tt>build_policy = "updated-deps"</tt>' as a line at the end of the file (no single quotes).
* Set up an alias that will run <tt>jhbuild</tt> in a stripped down environment that does not contain any reference to the Fink (/sw/...) or MacPorts (?) directories (if you have them): A good option is to set
:<pre>alias jhbuild="PATH=/opt/subversion/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin:~/gtk/inst ~/.local/bin/jhbuild"</pre>
* According to the [http://sourceforge.net/apps/trac/gtk-osx/wiki/Build description on Sourceforge], build PyGTK as follows:
** <tt>jhbuild bootstrap</tt>
** <tt>jhbuild build meta-gtk-osx-bootstrap</tt>
** <tt>jhbuild build meta-gtk-osx-core</tt>
** <tt>jhbuild pygtk</tt> (or [http://sourceforge.net/apps/trac/gtk-osx/wiki/PyGtk should it be]: <tt>meta-gtk-osx-python</tt> ?)

You can now test that PyGTK is working by running <tt>python</tt> and checking that <tt>import gtk</tt> doesn't cause errors.

If that's working, you should be able to use your working copy of ASCEND (as above) to run <tt>pygtk/ascdev</tt>. This should open ASCEND, but you may have to command-tab to the correct window, as it won't pop to the front automatically.

Here's a screenshot of ASCEND on Native GTK-Quartz on OS X!

[[Image:ASCENDnativeOSX.png|thumb|300px|none|Screenshot of the PyGTK GUI running on Mac OSX with GTK-OSX (Quartz/Native GTK)]]

'''Note''': currently, the ASCEND GUI on Mac still behaves much the same as it would on Windows or Linux; we haven't yet 'mackified' the keyboard shortcuts and menu layout. This will be using the 'ige-mac-integration' library that's also provided by the GTK-OSX project.

Note that allegedly it is also possible to build native GTK using macports, but we haven't yet tried that.

== Building the Tcl/Tk GUI ==

No work yet to determine what will be required to the Tcl/Tk GUI running on Mac.

It ''may'' be fairly straightforward to get this GUI running, possibly using these binaries for Tcl/Tk:

* http://www.categorifiedcoder.info/tcltk/

== Preparing for distribution ==

''The following part is still under development.''

Once GTK is build using jhbuild above, we need to re-package ASCEND in the form of a 'normal' Mac OS X application. To do this,

<source lang="a4c">cd ~/ascend
python scons/installgtk.py
scons install INSTALL_PREFIX=~/ascinst</source>

Those steps will first copy GTK and associated files into <tt>dist/PyGTK.bundle</tt>. Next, they will copy all the ASCEND files as well as PyGTK.bundle into ~/ascinst/ASCEND.app. Other files will be added to the ~/ascint folder, in preparation for making a .dmg disk image that will be suitable for distribution.

Currently, we are still working out some final bugs with the creation of the PyGTK.bundle, so this final step doesn't entirely work.

== Development notes ==

=== Packaging and distribution ===

It's recommended for most Mac applications that everything be distributed as an Application Bundle that just be dragged by the user into their Applications folder. This is certainly possible with ASCEND, but a problem is that the ASCEND Model Library is something that we would like users to see and interact with. We would like users to be able to see these folders and their contents easily using the Finder. Nesting the files within an Application bundle makes this rather difficult.

One option would be for the ASCEND application to unpack its model library to ~/Library/Application Support/ASCEND when the program is first run. This would require Python scripting, and would not be compatible with a shared installation of the Tcl/Tk GUI on the same system.

Another option would be to install the model library in /Library/Application Support/ASCEND/Models. This seems to be the right way forward, but it means that ASCEND can no longer just be dragged to the Applications folder to be installed. Instead, it would need an Installer to place the necessary files on the user's system. That's quite desirable, though, because such an installer could also check that the user has the correct versions of Python, GTK and PyGTK already installed on the system, and could even possibly download and install them first if required.

It's worth noting that Mac editors like TextEdit can't peer into Application Bundles, but non-Mac editors like gedit can do so... they don't impose the same restriction on entering inside such bundles.

As a first attempt for getting everything running, it seems wise to take the simple application bundle approach.

We're not currently proposing to provide the Tcl/Tk GUI for Mac. This is a whole separate packaging problem.

We're not currently proposing to package libascend as a Framework for Mac, although that is an option, and would be appropriate if attempting to provide both Tcl/Tk and PyGTK GUIs on the same machine, and to make it easier for users to develop their own solvers, etc, on that platform.

The general opinion on GTK is that we should include it within out Application Bundle. From the linux point of view, this is terribly inefficient, but such things are standard practise on Mac, and we should respect that in the first instance.

The alternative of providing ASCEND to the Mac community as a Fink package was considered, however, according to Fink developers, the current 'stable' repository for Fink is very stagnant, so we are unlikely to be able to use that as a means for distribution.

If we want to distribute ASCEND as a multi-component thing (libascend framework, Tcl/Tk GUI, PyGTK, model library all separate) then we would need to use the Apple tool, ''PackageMaker'', which allows developers to produce their own .pkg installers, apparently<ref>http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html</ref>. It is preferable to distribute a simple Application Bundle within a .dmg Disk Image.

=== Creating ASCEND.app ===

To create the ASCEND application bundle

* scons -j2 install INSTALL_PREFIX=~/ascinst
* The bundle will appear as ~/ascinst/ASCEND.app
* TODO: add necessary GTK files to the .app!
* follow instructions below to turn it into a redistributable disk image

The file {{src|mac/Info.plist}} contains all the key-value stuff describing the application. We had to make changes to {{src|pygtk/ascend.in}} to accommodate the particularities of the Mac platform, too.

=== Creating a Disk Image (ASCEND-0.9.X.dmg) ===

Some instructions are here: http://www.wikihow.com/Make-a-DMG-File-on-a-Mac

In summary:

* use the Applications/Utilities/Disk Utility application
* create a new image large enough for your needs
* mount and open the image
* from the Terminal, run scons -j2 install INSTALL_PREFIX=(location of your disk image folder)
* set the folder background image to ~/ascend/mac/folder-background.png
* arrange the files so that they look OK, the folder-background arrow should point from the ASCEND.app to the Applications folder alias.
* return to the disk image program
* click 'convert' and convert to a compressed image (OK to overwrite)
* all done, you can double-click the image file now, and it should mount and appear as you wanted it.

=== Finding all the GTK files ===

To create a safely porting ASCEND.app, we need to embed all of GTK into the application bundle. The above application won't be complete until we achieve that.

Looks like some Python packages called [http://docs.python.org/library/modulefinder.html modulefinder] (built-in to Python) or [http://pypi.python.org/pypi/modulegraph/ modulegraph] (external) may be able to help with locating all the necessary files for satisfying Python 'import' dependencies.

Then, [http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/otool.1.html otool] ('otool -L') can be used to find shared library dependencies.

There are also some other files such as bitmaps, 'locale' files, and maybe others that will be required for correct running of GTK; these also need to be bundled.

The tool [http://sourceforge.net/apps/trac/gtk-osx/wiki/Bundle ige-mac-bundler] seems to provide some degree of automation for this process, although it seems to be more oriented for C application than Python. We have some [[Porting_to_Mac/ige-mac-bundler|notes on how it works]].

The shell-script gimpguts.sh, available from GIMPskel.zip on [http://gimp-app.sourceforge.net/ this page] also contains some code for pulling in the necessary bits of GTK for packaging.

Our solution is a Python script that makes calls to 'otool' and 'modulefinder'. We hope to be able to incorporate this script into our SCons build scripts as a 'tool', but at the moment, {{src|scons/installgtk.py}} is standalone. This is still under development.

Most Mac libraries by default are hard-wired with absolute dependency paths as [http://blogs.sun.com/dipol/entry/dynamic_libraries_rpath_and_mac described by Joe Di Pol]. The solution seems to be to post-process the shared libraries after they have been copied, using 'install_name_tool'.

=== Problems with non-english Systems ===

You need to set your System to english - it's not about your system user interface language and not about your keyboard, it about the Formats.

Go to
System Preferences -> Interantional -> Formats

select english US and reboot your system.

If you do not take this step, ascend will ignore all decimal places.
PI will be 3.0000 instead of 3.1415, numbers like 0.12345 will be 0.00000 possibly causing "Division by Zero" Errors.

=== Problems With Matplotlib ===

[http://matplotlib.sourceforge.net/ Matplotlib] is used for all plotting by the PyGTK GUI, and Matplotlib in turn depends on [http://numpy.scipy.org/ NumPy]. NumPy doesn't work correctly with Apple's System Python, so you have to install MacPython to use the standard binary releases of Matplotlib and NumPy. Alternatively, it's possible to go back and download older versions of NumPy that ''do'' run on Apple's Python, but you'll presumably be losing some functionaly as a result.

The conclusion from all this is that it might be advisable for ASCEND on the Mac to be linked against MacPython, and for a runtime check to be made to ensure that the correct version is in place.

=== Connecting to Apple Events ===

Currently, GTK on Mac has no support for receiving or sending Apple Events. This is a problem, because Mac OS X attempts to communicate using Apple Events when a file is to be opened. If the app is not listening for events, then nothing will happen.

However, there seems to be a workaround for the case of Python scripts: [http://appscript.sourceforge.net appscript], which contains a module called [http://appscript.sourceforge.net/py-appscript/doc/aem-manual/05_targettingapplications.html py-aem]. It may be possible to incorporate this into ASCEND as a way for processing such events. There may be other similar modules, possible. Also, PyObjC may provide another way of creating event listeners. These modules are included by default with [http://www.python.org/download/mac/ MacPython].

According to GTK-OSX, there has not yet been any attempt to incorporate this stuff into ige-mac-integration, although it was agreed that it would be desirable to integrate it there (to benefit also C-based GTK applications ported to Mac).

An alternative approach might be to write a very small Carbon/Cocoa application that could do the event listening, and pass the events on to the main application.

=== Alternative approach: Homebrew? ===

A new method<ref>http://blog.abhiomkar.in/2010/01/02/macports-to-homebrew-new-packaging-system-for-mac-os-x/</ref> of obtaining GTK, SWIG, SCons and other tools is via [http://github.com/mxcl/homebrew Homebrew].

An initial check of Homebrew shows that although it provides GTK+, at this stage it only provides the X11 version of GTK+, which does not help with the task of creating native GTK+ ASCEND as desired here. Also, the 'gtk-demo' compiled by Homebrew seems to segfault, not sure what the reason for that was.

== References ==
<references/>

[[Category:Development]]
[[Category:Mac_OS_X]]

User:RichardTowers

2011-07-05T09:54:21Z

RichardTowers: /* Equations of State */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

Browse code: {{srcbranchdir|richard|models/johnpye/fprops}}
== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* <strike>[[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]</strike>
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''4th July 2011'''

Having discussed flexibility with regards to equation of state decided on the future structure of the program. Using various structs and unions fprops now has a skeleton capable of supporting several possible equations.

Still to do in this area: Actually implement other EOSs (peng-robinson first), Refactor FPROPS to fit with new way of doing things.

'''24th June 2011'''

Switched to Mac OS X for development, switched to the Xcode IDE for editing, hopefully the overheads in learning the new system will be worth it. Spoke to John about support for multiple equations of state, created a couple of files ready to start experimenting.

'''20th June 2011'''

All fluid files converted from source to XML, parser demonstrated to work for every file tried so far. Further features (multiple correlations from multiple sources etc.) should be relatively easy to implement now. Acquired a copy of Sandler "Chemical and Engineering Thermodynamics" which will be helpful in sorting out implementations of the cubic equations of state.

'''17 June 2011'''

Finished writing an xml parser and translating c data files to xml .fluid files. readFluidFile() from parser.c will now load data at run time. There's still a few features to be implemented here but it's up and running now.

'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/xml/hydrogen.fluid?view=markup hydrogen.fluid]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/parserMkII.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[Redlich Kwong EOS in FPROPS|Redlich Kwong]] & [[PengRobinson EOS in FPROPS|Peng Robinson]] cubic EOSs. See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup redkw.c], [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup redkw.h],
[http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

One of the main challenges here is to write functions which can take any correlation data struct as an input, decide which correlation to use, and return the desired value. After some consultation with John, we've decided on a struct containing all of the data and pointers to the various functions. A union is used to enable different types of data to be passed to functions with the same arguments.
<source lang="c">
/** Enumerate EOS correlations
*/
enum eos{
pengrob,
redkw,
helmholtz,
mbwr //etc.
};

/** Union for equation of state data
*/
typedef union eos_tag{
HelmholtzData* helmholtzData;
CubicData* cubicData;
//etc...
} EosData;

/** Definition of a fluid property function pointer
*/
typedef double (*propFnPtr)(double,double,const EosData*);

/**
Structure pointing to the necessary data and functions to calculate
fluid properties.
*/
typedef struct pureFluid{
enum eos type;
IdealData *idealData;
EosData *eosData;
//Pointers to departure functions
propFnPtr p_fn;
propFnPtr u_fn;
propFnPtr h_fn;
propFnPtr s_fn;
propFnPtr a_fn;
propFnPtr cv_fn;
propFnPtr cp_fn;
propFnPtr w_fn;
propFnPtr g_fn;
} pureFluid;
</source>

The structure can be created as follows, and then the function pointers can simply be followed to the correct function.
<source lang="c">
EosData eosData={.cubicData=&cData};
pureFluid fluidData={
pengrob,
&iData,
&eosData,
//Pointers to departure functions
pengrob_p,
pengrob_u_depart,
pengrob_h_depart,
pengrob_s_depart,
pengrob_a_depart,
pengrob_cv,
pengrob_cp,
pengrob_w,
pengrob_g_depart
};

double p=fluidData.p_fn(T,rho,fluidData.eosData);
</source>
[[Category:GSOC2011]]

User talk:Aakash

2011-07-04T16:49:27Z

RichardTowers: Blanked the page

User:RichardTowers

2011-07-04T16:48:17Z

RichardTowers: /* Equations of State - New code, should be moved to its own page probably.*/

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

Browse code: {{srcbranchdir|richard|models/johnpye/fprops}}
== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* <strike>[[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]</strike>
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''4th July 2011'''

Having discussed flexibility with regards to equation of state decided on the future structure of the program. Using various structs and unions fprops now has a skeleton capable of supporting several possible equations.

Still to do in this area: Actually implement other EOSs (peng-robinson first), Refactor FPROPS to fit with new way of doing things.

'''24th June 2011'''

Switched to Mac OS X for development, switched to the Xcode IDE for editing, hopefully the overheads in learning the new system will be worth it. Spoke to John about support for multiple equations of state, created a couple of files ready to start experimenting.

'''20th June 2011'''

All fluid files converted from source to XML, parser demonstrated to work for every file tried so far. Further features (multiple correlations from multiple sources etc.) should be relatively easy to implement now. Acquired a copy of Sandler "Chemical and Engineering Thermodynamics" which will be helpful in sorting out implementations of the cubic equations of state.

'''17 June 2011'''

Finished writing an xml parser and translating c data files to xml .fluid files. readFluidFile() from parser.c will now load data at run time. There's still a few features to be implemented here but it's up and running now.

'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/xml/hydrogen.fluid?view=markup hydrogen.fluid]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/parserMkII.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[Redlich Kwong EOS in FPROPS|Redlich Kwong]] & [[Peng Robinson EOS in FPROPS|Peng Robinson]] cubic EOSs. See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup redkw.c], [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup redkw.h],
[http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

One of the main challenges here is to write functions which can take any correlation data struct as an input, decide which correlation to use, and return the desired value. After some consultation with John, we've decided on a struct containing all of the data and pointers to the various functions. A union is used to enable different types of data to be passed to functions with the same arguments.
<source lang="c">
/** Enumerate EOS correlations
*/
enum eos{
pengrob,
redkw,
helmholtz,
mbwr //etc.
};

/** Union for equation of state data
*/
typedef union eos_tag{
HelmholtzData* helmholtzData;
CubicData* cubicData;
//etc...
} EosData;

/** Definition of a fluid property function pointer
*/
typedef double (*propFnPtr)(double,double,const EosData*);

/**
Structure pointing to the necessary data and functions to calculate
fluid properties.
*/
typedef struct pureFluid{
enum eos type;
IdealData *idealData;
EosData *eosData;
//Pointers to departure functions
propFnPtr p_fn;
propFnPtr u_fn;
propFnPtr h_fn;
propFnPtr s_fn;
propFnPtr a_fn;
propFnPtr cv_fn;
propFnPtr cp_fn;
propFnPtr w_fn;
propFnPtr g_fn;
} pureFluid;
</source>

The structure can be created as follows, and then the function pointers can simply be followed to the correct function.
<source lang="c">
EosData eosData={.cubicData=&cData};
pureFluid fluidData={
pengrob,
&iData,
&eosData,
//Pointers to departure functions
pengrob_p,
pengrob_u_depart,
pengrob_h_depart,
pengrob_s_depart,
pengrob_a_depart,
pengrob_cv,
pengrob_cp,
pengrob_w,
pengrob_g_depart
};

double p=fluidData.p_fn(T,rho,fluidData.eosData);
</source>
[[Category:GSOC2011]]

User:RichardTowers

2011-07-04T16:38:16Z

RichardTowers: /* Progress reports */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

Browse code: {{srcbranchdir|richard|models/johnpye/fprops}}
== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* <strike>[[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]</strike>
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''4th July 2011'''

Having discussed flexibility with regards to equation of state decided on the future structure of the program. Using various structs and unions fprops now has a skeleton capable of supporting several possible equations.

Still to do in this area: Actually implement other EOSs (peng-robinson first), Refactor FPROPS to fit with new way of doing things.

'''24th June 2011'''

Switched to Mac OS X for development, switched to the Xcode IDE for editing, hopefully the overheads in learning the new system will be worth it. Spoke to John about support for multiple equations of state, created a couple of files ready to start experimenting.

'''20th June 2011'''

All fluid files converted from source to XML, parser demonstrated to work for every file tried so far. Further features (multiple correlations from multiple sources etc.) should be relatively easy to implement now. Acquired a copy of Sandler "Chemical and Engineering Thermodynamics" which will be helpful in sorting out implementations of the cubic equations of state.

'''17 June 2011'''

Finished writing an xml parser and translating c data files to xml .fluid files. readFluidFile() from parser.c will now load data at run time. There's still a few features to be implemented here but it's up and running now.

'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/xml/hydrogen.fluid?view=markup hydrogen.fluid]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/parserMkII.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[Redlich Kwong EOS in FPROPS|Redlich Kwong]] cubic EOS, possibly adding some other equations in the same family (van der Waals and Peng-Robinson for example). See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup redkw.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup redkw.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

One of the main challenges here is to write functions which can take any correlation data struct as an input, decide which correlation to use, and return the desired value. The suggested method is to use a higher level struct which contains details of the correlation being used, and a pointer to the necessary data (along with NULL pointers to the other possible data):
<source lang="c">
typedef struct eosData{
short ID;
HelmholtzData* helmholtz;
CubicData* cubic;
//Add more as new equations of state are added,
//each eos should have its own header file defining the structs
} EosData;
</source>
A high level function then takes this data, uses the ID flag to decide on the correlation, and calls the appropriate function. Potentially function pointers could simplify the code here:
<source lang="c">
double fprops_p(double T, double rho, const EosData *data) {
switch(data->ID) {
case PENGROBINSON:
//Not yet implemented...
break;
case REDKW:
return redkw_p(T,rho,data->cubic);
break;
case HELMHOLTZ:
return helmholtz_p(T,rho,data->helmholtz);
break;
case MBWR:
//Not yet implemented...
break;
default:
fprintf(stderr, "fprops_p error: Unrecognised correlation ID: %d\n", data->ID);
break;
}
}
</source>
[[Category:GSOC2011]]

User:RichardTowers

2011-06-26T11:57:46Z

RichardTowers: /* Equations of State */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

Browse code: {{srcbranchdir|richard|models/johnpye/fprops}}
== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* <strike>[[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]</strike>
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''24th June 2011'''

Switched to Mac OS X for development, switched to the Xcode IDE for editing, hopefully the overheads in learning the new system will be worth it. Spoke to John about support for multiple equations of state, created a couple of files ready to start experimenting.

'''20th June 2011'''

All fluid files converted from source to XML, parser demonstrated to work for every file tried so far. Further features (multiple correlations from multiple sources etc.) should be relatively easy to implement now. Acquired a copy of Sandler "Chemical and Engineering Thermodynamics" which will be helpful in sorting out implementations of the cubic equations of state.

'''17 June 2011'''

Finished writing an xml parser and translating c data files to xml .fluid files. readFluidFile() from parser.c will now load data at run time. There's still a few features to be implemented here but it's up and running now.

'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/xml/hydrogen.fluid?view=markup hydrogen.fluid]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/parserMkII.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[Redlich Kwong EOS in FPROPS|Redlich Kwong]] cubic EOS, possibly adding some other equations in the same family (van der Waals and Peng-Robinson for example). See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup redkw.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup redkw.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

One of the main challenges here is to write functions which can take any correlation data struct as an input, decide which correlation to use, and return the desired value. The suggested method is to use a higher level struct which contains details of the correlation being used, and a pointer to the necessary data (along with NULL pointers to the other possible data):
<source lang="c">
typedef struct eosData{
short ID;
HelmholtzData* helmholtz;
CubicData* cubic;
//Add more as new equations of state are added,
//each eos should have its own header file defining the structs
} EosData;
</source>
A high level function then takes this data, uses the ID flag to decide on the correlation, and calls the appropriate function. Potentially function pointers could simplify the code here:
<source lang="c">
double fprops_p(double T, double rho, const EosData *data) {
switch(data->ID) {
case PENGROBINSON:
//Not yet implemented...
break;
case REDKW:
return redkw_p(T,rho,data->cubic);
break;
case HELMHOLTZ:
return helmholtz_p(T,rho,data->helmholtz);
break;
case MBWR:
//Not yet implemented...
break;
default:
fprintf(stderr, "fprops_p error: Unrecognised correlation ID: %d\n", data->ID);
break;
}
}
</source>
[[Category:GSOC2011]]

User:RichardTowers

2011-06-24T19:48:12Z

RichardTowers: /* Progress reports ~ 24th*/

User talk:Aakash

2011-06-24T18:32:36Z

RichardTowers: Hello Aakash!

Hi Aakash, I'm Richard, a fellow GSOC 2011 student. Our areas of interest are very different, but I mentioned to John that I'd switched to developing on a Mac and he said I ought to get in touch with you.

If you need any OS X code testing, or if there's anything I can help with, just give me a shout. [[User:RichardTowers|RichardTowers]] 18:32, 24 June 2011 (UTC)

User:RichardTowers

2011-06-21T13:33:18Z

RichardTowers: /* Separating Correlation Coefficients */

User:RichardTowers

2011-06-21T13:28:59Z

RichardTowers: /* Progress reports */

User:RichardTowers

2011-06-17T17:15:22Z

RichardTowers: /* Progress reports */

User:RichardTowers

2011-06-17T17:12:42Z

RichardTowers: /* Goals - finished parser/xml*/

Redlich Kwong EOS in FPROPS

2011-06-15T10:15:17Z

RichardTowers: /* Departure Functions */

{{task}}
Work on this continues as part of GSoC 2011 ([[User:richardTowers|Richard Towers]]). See also [[FPROPS]], [[PengRobinson EOS in FPROPS]].
==Overview==
The Redlich-Kwong equation of state is one of several cubic equations of state that FPROPS aims to implement in the future. In its basic form it relates pressure to temperature and relative volume:

<math>
\begin{align}
P=\frac{RT}{V-b}-\frac{a}{V(V+b)}
\end{align}
</math>

==Departure Functions==
Other thermodynamic properties can be calculated from the departure functions:

Helmholtz Energy:

<math>
\begin{align}
A-A^{0}=-RT\ln\frac{V-b}{V}-\frac{a}{b}\ln\frac{V+b}{V}-RT\ln\frac{V}{V^{0}}
\end{align}
</math>

Entropy:

<math>
\begin{align}
S-S^{0}=R\ln\frac{V-b}{V}-\frac{a}{2bT}\ln\frac{V+b}{V}+R\ln\frac{V}{V^{0}}
\end{align}
</math>

Enthalpy:

<math>
\begin{align}
H-H^{0}=\frac{bRT}{V-b}-\frac{a}{V+b}-\frac{3a}{2b}\ln\frac{V+b}{V}
\end{align}
</math>

Internal Energy:

<math>
\begin{align}
U-U^{0}=-\frac{3a}{2b}\ln\frac{V+b}{V}
\end{align}
</math>

Gibbs free energy:

<math>
\begin{align}
G-G^{0}=\frac{bRT}{V-b}-\frac{a}{V+b}-RT\ln\frac{V-b}{V}-\frac{a}{b}\ln\frac{V+b}{V}-RT\ln\frac{V}{V^{0}}
\end{align}
</math>

Specific Heat Capacity at Constant Pressure:

Specific Heat Capacity at Constant Temperature:

==Other Properties==
Fugacity:

<math>
\begin{align}
\ln\frac{f}{P}=\frac{b}{V-b}-\frac{a}{RT(V+b)}-\ln\frac{V-b}{V}-\frac{a}{bRT}\ln\frac{V+b}{V}-\ln\left(\frac{V}{V-b}-\frac{a}{RT(V+b)}\right)
\end{align}
</math>

User:RichardTowers

2011-06-15T09:56:31Z

RichardTowers: /* Equations of State */

User:RichardTowers

2011-06-12T14:54:29Z

RichardTowers: /* Progress reports */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* [[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''12 June 2011'''

Found a function to calculate critical pressure in sat.c, made this public and used it in redkw.c. In the process of testing the results now.
Should still probably rewrite in terms of reduced vars, and still need to think about V_0. Also remaining dep. functions need deriving. Once that's nailed there's some computing on the horizon...

'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/hydrogen.xml?view=markup hydrogen.xml]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/parser.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[PengRobinson EOS in FPROPS|Peng-Robinson]] cubic EOS, possibly adding some other equations in the same family (van der Waals, Redlich-Kwon and Soave for example). See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup pengrobinson.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

[[Category:GSOC2011]]

User:RichardTowers

2011-06-11T19:37:41Z

RichardTowers: /* Progress reports */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* [[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''11 June 2011'''

The simpler departure functions for Redlich Kwon are nearly implemented now (see [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/redkw.c?revision=3481&view=markup&pathrev=3481 redkw.c]). The functions should probably be rewritten in terms of reduced variables, which may eliminate the (currently terminal) problem of unspecified critical pressure. Also careful consideration needs to be given to the value of <math>V^0</math>, this seems to be related to a reference state, which needs to be defined. Finally the calculation of Redlich-Kwong coefficients should be moved so that they're calculated a minimum number of times, we'll need some variables for this.

'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/hydrogen.xml?view=markup hydrogen.xml]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/parser.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[PengRobinson EOS in FPROPS|Peng-Robinson]] cubic EOS, possibly adding some other equations in the same family (van der Waals, Redlich-Kwon and Soave for example). See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup pengrobinson.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

[[Category:GSOC2011]]

PengRobinson EOS in FPROPS

2011-06-09T11:32:41Z

RichardTowers: Removed Ankit's code etc. since the focus of this has shifted.

Redlich Kwong EOS in FPROPS

2011-06-09T11:20:50Z

RichardTowers: /* Overview */

{{task}}
Work on this continues as part of GSoC 2011 ([[User:richardTowers|Richard Towers]]). See also [[FPROPS]], [[PengRobinson EOS in FPROPS]].
==Overview==
The Redlich-Kwong equation of state is one of several cubic equations of state that FPROPS aims to implement in the future. In its basic form it relates pressure to temperature and relative volume:

<math>
\begin{align}
P=\frac{RT}{V-b}-\frac{a}{V(V+b)}
\end{align}
</math>

==Departure Functions==
Other thermodynamic properties can be calculated from the departure functions:

<math>
\begin{align}
A-A^{0}=-RT\ln\frac{V-b}{V}-\frac{a}{b}\ln\frac{V+b}{V}-RT\ln\frac{V}{V^{0}}
\end{align}
</math>

<math>
\begin{align}
S-S^{0}=R\ln\frac{V-b}{V}-\frac{a}{2bT}\ln\frac{V+b}{V}+R\ln\frac{V}{V^{0}}
\end{align}
</math>

<math>
\begin{align}
H-H^{0}=\frac{bRT}{V-b}-\frac{a}{V+b}-\frac{3a}{2b}\ln\frac{V+b}{V}
\end{align}
</math>

<math>
\begin{align}
U-U^{0}=-\frac{3a}{2b}\ln\frac{V+b}{V}
\end{align}
</math>

<math>
\begin{align}
G-G^{0}=\frac{bRT}{V-b}-\frac{a}{V+b}-RT\ln\frac{V-b}{V}-\frac{a}{b}\ln\frac{V+b}{V}-RT\ln\frac{V}{V^{0}}
\end{align}
</math>

<math>
\begin{align}
\ln\frac{f}{P}=\frac{b}{V-b}-\frac{a}{RT(V+b)}-\ln\frac{V-b}{V}-\frac{a}{bRT}\ln\frac{V+b}{V}-\ln\left(\frac{V}{V-b}-\frac{a}{RT(V+b)}\right)
\end{align}
</math>

User:RichardTowers

2011-06-09T11:20:05Z

RichardTowers: /* Progress reports */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* [[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''9 June 2011'''

See [[Redlich Kwong EOS in FPROPS]] for details of current thoughts on its implementation.

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/hydrogen.xml?view=markup hydrogen.xml]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/parser.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[PengRobinson EOS in FPROPS|Peng-Robinson]] cubic EOS, possibly adding some other equations in the same family (van der Waals, Redlich-Kwon and Soave for example). See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup pengrobinson.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

[[Category:GSOC2011]]

Redlich Kwong EOS in FPROPS

2011-06-09T11:19:31Z

RichardTowers: Basics of Redlich Kwong

{{task}}
Work on this continues as part of GSoC 2011 ([[User:richardTowers|Richard Towers]]). See also [[FPROPS]], [[PengRobinson EOS in FPROPS]].
==Overview==
The Redlich-Kwong equation of state is one of several cubic equations of state that FPROPS aims to implement in the future. In its basic form it relates pressure to temperature and relative volume:

<math>
\begin{align}
P=\frac{RT}{V-b}-\frac{a}{V(V+b)}
\end{align}
</math>

Other thermodynamic properties can be calculated from the departure functions:

<math>
\begin{align}
A-A^{0}=-RT\ln\frac{V-b}{V}-\frac{a}{b}\ln\frac{V+b}{V}-RT\ln\frac{V}{V^{0}}
\end{align}
</math>

<math>
\begin{align}
S-S^{0}=R\ln\frac{V-b}{V}-\frac{a}{2bT}\ln\frac{V+b}{V}+R\ln\frac{V}{V^{0}}
\end{align}
</math>

<math>
\begin{align}
H-H^{0}=\frac{bRT}{V-b}-\frac{a}{V+b}-\frac{3a}{2b}\ln\frac{V+b}{V}
\end{align}
</math>

<math>
\begin{align}
U-U^{0}=-\frac{3a}{2b}\ln\frac{V+b}{V}
\end{align}
</math>

<math>
\begin{align}
G-G^{0}=\frac{bRT}{V-b}-\frac{a}{V+b}-RT\ln\frac{V-b}{V}-\frac{a}{b}\ln\frac{V+b}{V}-RT\ln\frac{V}{V^{0}}
\end{align}
</math>

<math>
\begin{align}
\ln\frac{f}{P}=\frac{b}{V-b}-\frac{a}{RT(V+b)}-\ln\frac{V-b}{V}-\frac{a}{bRT}\ln\frac{V+b}{V}-\ln\left(\frac{V}{V-b}-\frac{a}{RT(V+b)}\right)
\end{align}
</math>

User:RichardTowers

2011-06-09T10:49:39Z

RichardTowers: /* Progress reports - Departure fns from RP&P*/

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

== Goals ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* [[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Progress reports ==
'''9 June 2011'''

From Reid, Prausnitz and Poling, for the Redlich-Kwong EOS:

<math>
\begin{align}
A-A^{0}=-RT\ln\frac{V-b}{V}-\frac{a}{b}\ln\frac{V+b}{V}-RT\ln\frac{V}{V^{0}}
\end{align}
</math>

<math>
\begin{align}
S-S^{0}=R\ln\frac{V-b}{V}-\frac{a}{2bT}\ln\frac{V+b}{V}+R\ln\frac{V}{V^{0}}
\end{align}
</math>

<math>
\begin{align}
H-H^{0}=\frac{bRT}{V-b}-\frac{a}{V+b}-\frac{3a}{2b}\ln\frac{V+b}{V}
\end{align}
</math>

<math>
\begin{align}
U-U^{0}=-\frac{3a}{2b}\ln\frac{V+b}{V}
\end{align}
</math>

<math>
\begin{align}
G-G^{0}=\frac{bRT}{V-b}-\frac{a}{V+b}-RT\ln\frac{V-b}{V}-\frac{a}{b}\ln\frac{V+b}{V}-RT\ln\frac{V}{V^{0}}
\end{align}
</math>

<math>
\begin{align}
\ln\frac{f}{P}=\frac{b}{V-b}-\frac{a}{RT(V+b)}-\ln\frac{V-b}{V}-\frac{a}{bRT}\ln\frac{V+b}{V}-\ln\left(\frac{V}{V-b}-\frac{a}{RT(V+b)}\right)
\end{align}
</math>

'''4 June 2011'''

Record of an email sent by [[John Pye]] to Richard:

Looking at Reid, Prausnitz & Poling (I have the 4th edition) it might be that you will have an easier time getting started with Redlich-Kwong equations of state, rather than the Peng-Robinson ones. The EOS is detailed in Section 3-4 "Cubic Equations of State" and the derivation of so-called 'departure functions' is detailed in Example 5-1 "Derive the departure functions for a pure material...". This derivation includes functions for calculation of extensive properties A, S, H, U, G. Some additional partial derivatives should give you Cp, Cv, and then you need also to convert to the intensive properties. How to use these departure functions to calculate is detailed in Section 5-2 "Fundamental Thermodynamic Principles", eg eq 5-2.4.

Let me put the above into the context of the current code. The eq 5-2.5 contains an ideal part (an integral of Cp°), a 'departure function'. The departure functions are functions exclusively of the p-v-T surface, ie the EOS. So given the EOS we can do the maths to work out what these departure functions need to be. This is done for the Helmholtz approach in the file helmholtz.c: see the functions eg helmholtz_h_raw, which shows the ideal and the 'residual' (departure) parts clearly. The residual parts are then implemented further down in that file.

I would propose then that to do a RK or PR EOS, we can keep most of helmholtz.[ch] and simply calculate new functions like helm_resid_tau and so on, specific to the EOS in question. All the current stuff from ideal.c continues to be used as-is, and the saturation calculation also remains as-is. We just need new functions like redkw_resid, redkw_resid_del, redkw_resid_tau, etc.

Doing the maths for those functions will need to be extremely carefully done, as from my experience is very very easy to introduce little calculation errors along the way. A good idea is to make use of tools like wxMaxima or similar, to do some of the maths symbolically, even if only as a double-check for hand-calculation. You then need to take the resulting expressions and work out how to code them efficiently.

We will of course then need to work out suitable data-structrues that allow functions like helmholtz_h_raw (renamed to fprops_h_raw, perhaps) to be common. That will require the HelmholtzData structure to be generalised to contain some pointer to the a struct containing the necessary residual functions, I suspect.

Further to the above, we will have to ponder how to implement support for thermo derivatives (derivs.[ch]). I think that this requires additional functions helmholtz_betap and helmholtz_alphap to be generalised as well. That might be trivial, actually.

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/hydrogen.xml?view=markup hydrogen.xml]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/parser.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the [[PengRobinson EOS in FPROPS|Peng-Robinson]] cubic EOS, possibly adding some other equations in the same family (van der Waals, Redlich-Kwon and Soave for example). See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup pengrobinson.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

[[Category:GSOC2011]]

User:RichardTowers

2011-06-08T16:19:36Z

RichardTowers: /* Equations of State */

PengRobinson EOS in FPROPS

2011-06-08T11:11:48Z

RichardTowers: Punctuation

{{task}}
Work on this is went on as a part of GSoC 2010 (Project [[User:Ankitml|Ankit]]) and continues as part of GSoC 2011 ([[User:richardTowers|Richard Towers]]).
See also [[FPROPS]].

Comments and suggestions are welcome
==Overview==
The Peng-Robinson EOS is a cubic equation of state in that it contains volume terms to the third power, it is one of several equations of state that can be expressed in the form
:<math>
\begin{align}
P=\frac{RT}{V-b}-\frac{a}{V^2+ubV+wb^2}
\end{align}
</math>
or
:<math>
\begin{align}
Z^3-(1+B^*-uB^*)Z^2+(A^*+wB^{*2}-uB^*-uB^{*2})Z-A^*B^*-wB^{*2}-wB^{*3}=0
\end{align}
</math>
Where
:<math>
\begin{align}
A^*=\frac{aP}{R^2T^2}
\end{align}
</math>
:<math>
\begin{align}
B^*=\frac{bP}{RT}
\end{align}
</math>
In the Peng-Robinson values for <math>u,</math> <math>w</math>, <math>b</math> and <math>a</math> are set as
:<math>
\begin{align}
u=2
\end{align}
</math>
:<math>
\begin{align}
w=-1
\end{align}
</math>
:<math>
\begin{align}
b=\frac{0.7780RT_c}{P_c}
\end{align}
</math>
:<math>
\begin{align}
a=\frac{0.45724R^2T_c^2}{P_c}[1+f\omega(1-T_r^{\frac{1}{2}})]^2
\end{align}
</math>
:<math>
\begin{align}
f\omega=0.37464+1.54226\omega-0.26992\omega^2
\end{align}
</math>
So, for given values of <math>R</math>, <math>T_c</math>, <math>T_r</math>, <math>P_c</math> and <math>\omega</math> we can solve for <math>Z</math>. What next??
==Algorithm==
===Algorithm From Literature===
*Guess a Pressure.
*Find roots of volume using PR-EOS, if roots<3 guess P again.
*Min V is the molar liquid volume, and the max V is vapour molar volume.
*get Zl and Zv.
*Get fugacities of both phases.
*Pnew = Pold*fl/fv

===The current Algorithm===
*Calculate PV data using PR_EOS from 0.001 to 6666 cm3/mol.
*Get the range of Pressure in which volume has 3 roots.
*Give this range as lower and upper bounds to a golden search algorithm, minimizing the difference in fugacities.
*To calculate fugacities a non iterative analytical expression was derived for PR-EOS.

===Issues That Forced to Deviate From Literature===
*Find a non iterative way to solve a cubic Equation for volume. The normal iterative one makes the algorithm very slow, as it is required to solve the volume cubic many number of times to arrive at the solution. So right now generating PV data for a range with a constant increment in V.
*This also helps in guessing the first P in the range of 3 roots, which is required as the first step.
*The golden search algorithm is just experimental over the standard Pnew = Pold*Fl/Fv iteration, which requires a good guess whereas Golden search requires a bracket in which solution lies. It is yet to be tested which one is better.

==Limitations==
===Errors===
*Not working at some temperatures. [It should work on entire range from triple point to Critical Temperature]

[Solution] - Currently trying got find out the reason for this behaviour. - [http://ascendwiki.cheme.cmu.edu/User:Ankitml Ankit ]

*Not predicting Saturation Volumes for Liquids correctly.
[Solution] - Its a problem with Peng Robinson EOS, a modification to PR_EOS was proposed by G. Heyen in the paper, "Liquid and Vapor Properties from a cubic Equation of state", in 2nd International Conference on Phase Equilibria and Fluid Properties, 1980.

===Changes to be done to integrate with ASCEND===
*Data (Pc,Tc,Omega) to be taken from data files and only component name should be required in the code.
*No main function
*ASCEND wrapper
*Code should be in C, remove C++ functions.

=Code=
<source lang="c">
#include <stdio.h>
#include <math.h>
#include <iostream>
using namespace std;

//Global Variables
double Tc,Pc,Omega,R,Tre,b,a,RT,T,P[20000],V[20000],Phil,Phiv,Vl,Vv;
int j;

int noRoots(double Psat); //gives out number of roots (of V) at a particular Pressure
double Pcalc(double T, double V); // Calculates Pressure at Given T and V using PR-EOS
int PhiCalc(double PsatGuess); //Calculates fugacities at a given Pressure and Stores it in global variables
double phiDiff(double Pguess); //Finds fugacity difference at a particular P, uses function PhiCalc and is required for golden search algorithm
double goldSer(double a,double c,double b); //Golden search algorithm, function to be minimized is phiDiff and a is the lower bound, b is upper bound, c is the center.

int main()
{

Tc = 304.1282; // Kelvin
Pc = 73.773; // bar
Omega = 0.22394; // acentric factor
R = 83.14; //bar[cm3]/k/mol
T = 260;
RT = R*T;
Tre = T/Tc;

double p[20000],v[20000];
//following for loop calculates P V data till v=6500cm3/mol and stores it in P,V arrays only if P is within bounds of 60 and -160
j = 0;
for (int i=0;i<20000;i++)
{
v[i] = (i + 0.001)/3;
p[i] = Pcalc(T,v[i]);
if(p[i]<60.0 && p[i]>-160.0)
{
P[j] = p[i];
V[j] = v[i];
j++;
}
}

//finding the bounds for P
double pStart,deltaP;
pStart = 0.01;
deltaP = 1.0;
for(int n = 0;n<3;n++)
{
for(double pp = pStart;pp<60.0;pp=pp+deltaP)
{
int nor;
nor = noRoots(pp);
if (nor==3)
{
pStart = pp - deltaP;
pp = 59.0;
}
}
deltaP = deltaP/10;
}
pStart = pStart + 0.01;

double pEnd;
pEnd = pStart;
deltaP = 1.0;
for(int n = 0;n<2;n++)
{
for(double pp = pEnd;pp<60.0;pp=pp+deltaP)
{
int nor;
nor = noRoots(pp);
if (nor<3)
{
pEnd = pp - deltaP;
pp = 5000;
}
}
deltaP = deltaP/10;
}

int sandbox;
double Pa,Pb,Pc,sol,phi,resphi;
phi = (1 + sqrt(5))/2;
resphi = 2 - phi;
Pa = pStart;
Pb = pEnd;
Pc = (Pb - Pa)*resphi + Pa;
sol = goldSer(Pa,Pc,Pb);
sandbox=PhiCalc(sol);
cout<<"Molar Volume (L) = "<<Vl<<" cm3/mol"<<'\n';
cout<<"Molar Volume (V) = "<<Vv<<" cm3/mol"<<'\n';
cout<<"Difference in fugacities of vapour and liquid = "<<fabs(Phil-Phiv)<<'\n';
cout<<T<<'\t'<<sol<<'\t'<<Vl<<'\t'<<Vv<<'\t'<<fabs(Phil-Phiv)<<'\n';

return 0;
}

int noRoots(double Psat)
{
double Vroot[3];
Vroot[0] = -99; Vroot[1] = -99; Vroot[2] = -99;
int rootCount = 0;
for (int i = 0; i < j-1;i++)
{
if((Psat<=P[i+1] && Psat>=P[i]) || (Psat>=P[i+1] && Psat<=P[i]))
{
Vroot[rootCount] = V[i]+(Psat-P[i])*(V[i+1]-V[i])/(P[i+1]-P[i]);
rootCount++;
}
}
return rootCount;
}

double Pcalc(double T, double V)
{
double P,m,tmp;
b = 0.0778*R*Tc/Pc;
m = 0.37464+1.54226*Omega-0.26992*pow(Omega,2);
tmp = 1+m*(1-sqrt(Tre));
a = 0.45724*R*R*Tc*(Tc/Pc)*pow(tmp,2);
P = R*T/(V-b) - a/(V*(V+b)+b*(V-b));
return P;
}

int PhiCalc(double PsatGuess)
{ double Vroot[3],A,B;
B = PsatGuess*b/RT;
A = a*PsatGuess/pow(RT,2);
Vroot[0] = -99; Vroot[1] = -99; Vroot[2] = -99;
int rootCount = 0;
for (int i = 0; i < j-1;i++)
{
if((PsatGuess<=P[i+1] && PsatGuess>=P[i]) || (PsatGuess>=P[i+1] && PsatGuess<=P[i]))
{
Vroot[rootCount] =V[i]+(PsatGuess-P[i])*(V[i+1]-V[i])/(P[i+1]-P[i]);
rootCount++;
}
}

double Zv,Zl;
double term_a,term_b,term_c;

Vl = Vroot[0]; //liquid volume is the smaller root
Vv = Vroot[2]; // vapour volume is the largest one

Zl = PsatGuess*Vl/(R*T); //the corresponding Z
Zv = PsatGuess*Vv/(R*T);

term_a = (1 + sqrt(2))*B;
term_b = (1 - sqrt(2))*B;
term_c = 2*sqrt(2)*B;

Phil = (Zl-1) - log(Zl-B) - A/term_c*log((Zl+term_a)/(Zl+term_b));
Phiv = (Zv-1) - log(Zv-B) - A/term_c*log((Zv+term_a)/(Zv+term_b));
return 0;
}

double phiDiff(double Pguess)
{
double phiD;
int sandbox;
sandbox = PhiCalc(Pguess);
phiD = fabs(Phil - Phiv);
return phiD;
}

double goldSer(double a,double c,double b)
{
double d,phi,resphi;
phi = (1 + sqrt(5))/2;
resphi = 2 - phi;
if (fabs(a-b)<0.000001)
return ((a+b)/2);

d = c + resphi*(b - c);

if (phiDiff(d)<phiDiff(c))
return goldSer(c,d,b);
else
return goldSer(d,c,a);
}

</source>
==Possible Improvements in the code==

* Maybe this is of interest: http://pubs.acs.org/doi/abs/10.1021/ed066p54.2 ? [[User:Jpye|Jpye]] 06:39, 5 August 2010 (UTC)

==Comparisons==

[[Category:Development]]

User:RichardTowers

2011-06-03T08:26:12Z

RichardTowers: /* Initial Thoughts -> Goals*/

User:RichardTowers

2011-06-03T08:25:23Z

RichardTowers: /* Parser */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

== Initial Thoughts ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* [[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/hydrogen.xml?view=markup hydrogen.xml]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/parser.c?view=markup parser.c].

== Equations of State ==
Firstly I'll be looking at the Peng-Robinson cubic EOS, possibly adding some other equations in the same family (van der Waals, Redlich-Kwon and Soave for example). See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup pengrobinson.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

[[Category:GSOC2011]]

FPROPS

2011-06-02T16:50:07Z

RichardTowers: /* Implementation - Moved peng robinson to PengRobinson EOS in FPROPS */

<div style="float:right;border:solid 1pt green;background-color=#EEFFEE;width:18em;padding:12px">
'''Fluids supported by FPROPS'''

{{fpropsfluid|ammonia}}, {{fpropsfluid|nitrogen}}, {{fpropsfluid|hydrogen}}, {{fpropsfluid|water}}, {{fpropsfluid|carbondioxide}}, {{fpropsfluid|methane}}, {{fpropsfluid|carbonmonoxide}}, {{fpropsfluid|ethanol}}, {{fpropsfluid|acetone}}, {{fpropsfluid|carbonylsulfide}}, {{fpropsfluid|decane}}, {{fpropsfluid|hydrogensulfide}}, {{fpropsfluid|isohexane}}, {{fpropsfluid|isopentane}}, {{fpropsfluid|krypton}}, {{fpropsfluid|neopentane}}, {{fpropsfluid|nitrousoxide}}, {{fpropsfluid|nonane}}, {{fpropsfluid|sulfurdioxide}}, {{fpropsfluid|toluene}}, {{fpropsfluid|xenon}}, {{fpropsfluid|butane}}, {{fpropsfluid|butene}}, {{fpropsfluid|cisbutene}}, {{fpropsfluid|isobutene}}, {{fpropsfluid|transbutene}}, {{fpropsfluid|dimethylether}}, {{fpropsfluid|ethane}}, {{fpropsfluid|parahydrogen}}, {{fpropsfluid|isobutane}}, {{fpropsfluid|r41}}, {{fpropsfluid|r116}}, {{fpropsfluid|r141b}}, {{fpropsfluid|r142b}}, {{fpropsfluid|r218}}, {{fpropsfluid|r245fa}}

(in svn, at r3042)
</div>
'''FPROPS''' is a free open-source C-based library for high-accuracy evaluation of thermodynamic properties for a number of pure substances. It makes use of published data for the Helmholtz fundamental equation for those substances. It has been developed by [[User:Jpye|John Pye]] and [[#Contributors|others]], and will happily function as standalone code, but is also provided with [[external library]] code for ASCEND so that it can be used to access these accurate property correlations from within a [[MODEL]].

Currently FPROPS supports calculation of the properties of the pure substances shown on the right. The properties that can be calculated are internal energy <math>u</math>, entropy <math>s</math>, pressure <math>p</math>, enthalpy <math>h</math> and Helmholtz energy <math>a</math>, as well as various partial derivatives of these with respect to temperature and density.

FPROPS reproduces a limited subset of the functionality of commercial programs such as [http://www.nist.gov/srd/nist23.htm REFPROP], [http://gibbs.mech.kyushu-u.ac.jp/~akasaka/propath_man/ PROPATH], EES, [http://www.ruhr-uni-bochum.de/thermo/Software/Seiten/Fluidcal-eng.htm FLUIDCAL], [[freesteam]], SteamTab, and others, but is free open-source software, licensed under the [http://www.gnu.org/licenses/gpl.html GPL]. Contributions are most welcome!

Enhancement to FPROPS feature set and list of supported fluids has been going on as part of ASCEND's involvement in [[GSOC2010]].

FPROPS is included with ASCEND as of version 0.9.5.116, or you can browse the code at {{srcdir|models/johnpye/fprops/}} or access it [[VersionManagement|via subversion]] (code is evolving rapidly, as of Aug 2010).

== Implementation ==

The calculation routines implement calculation of reduced Helmholtz energy <math>\phi = a / R T</math> as a function of reduced density <math>\delta = \rho / \rho_c</math> and ''inverse'' reduced temperature <math>\tau = T_c / T</math>, by dividing it into ideal <math>\phi^0 \left(\tau,\delta\right)</math> and 'real' or 'residual' <math>\phi^r \left(\tau,\delta \right)</math> parts, as described in IAPWS-95<ref name=iapws95>http://www.iapws.org/relguide/IAPWS95-Rev.pdf</ref>.

=== Ideal part ===

Calculation of the '''ideal part''' of the reduced Helmholtz energy is derived from the expression for the zero-pressure limit of reduced specific heat capacity at constant pressure, <math>c_p^0 / R</math>, where <math>R</math> is the specific gas constant. This quantity <math>{c_p^0}(T)/R</math> can be expressed as a series composed of two different types of terms:

{| border="1" cellpadding="3" cellspacing="0"
! type !! expression !! correlation constants
|-
| power terms || <math>c_i T^{t_i}</math> || <math>c, t</math>
|-
| exponential terms (also called 'Einstein' terms<ref>Lemmon, E.W. and Span, R.,
2006, ''Short Fundamental Equations of State for 20 Industrial Fluids'', J. Chem. Eng. Data, '''51''', 785-850, {{doi|10.1021/je050186n}}</ref>) || <math>\frac{b_i x_i^2 exp(-x_i)}{[1-exp(-x_i)]^2}</math> where <math>x_i = \frac{\beta_i}{T}</math> || <math>b, \beta</math>
|}

An expression for calculating the ideal component of Helmholtz energy <math>a^0 \left(T , \rho \right)</math> from <math>c_p^0</math> is given by Span et al<ref>Span & Wagner (1996), "A new equation of state for carbon dioxide covering from the triple point temperature to 1100 K at pressures up to 800 MPa" ''J. Phys. Chem. Ref. Data'', '''25''' p 1509 ff, http://link.aip.org/link/?jpr/25/1509%26agg=NIST, {{doi|10.1063/1.555991}}</ref>:

:<math>\frac{a^0}{RT} = \phi^0 = \frac{h_0^0 \tau}{R T_c} - \frac{s_0^0}{R} - 1 + \ln {\frac{\delta / \delta_0}{\tau / \tau_0}} - \frac{\tau}{R} \int_{\tau_0}^{\tau}{\frac{c_p^0}{\tau^2}d\tau} + \frac{1}{R} \int_{\tau_0}^{\tau}{\frac{c_p^0}{\tau} d \tau}</math>

where the '''reduced temperature''' is <math>\tau = \frac{T^{*}}{T}</math> and the '''reduced density''' is <math>\delta = \frac{\rho}{\rho^{*}}</math>.

On the other hand, using the relations for the Helmholtz fundamental equation, one can see that

:<math>\frac{c_p^0}{R} = 1 -\tau^2 \phi^0_{\tau \tau}</math>

so coefficients of <math>c_p^0</math> can be calculated from coefficients of <math>\phi^0</math> (providing, we assume, that the fundamental equation has smooth first and second (and possibly third) derivatives, and that when terms of <math>{c_p^0}(T)</math> are integrated they don't 'interact'). One can go the other way, and determine <math>\phi^0</math> from <math>c_p^0</math>, with the exception of the integration constants, which are, in that case, determined using specified values of enthalpy <math>h^0_{ref}</math> and entropy <math>s^0_{ref}</math> at a reference state <math>\left(T_{ref},\rho_{ref} \right)</math>

=== Residual part ===

For the '''residual part''' of the reduced Helmholtz energy, FPROPS currently supports three different kinds of terms:

{| border="1" cellpadding="3" cellspacing="0"
! type !! expression !! correlation constants
|-
| power terms || <math>

\begin{cases}
a_i \tau^{t_i} \delta^{d_i} exp(-\delta^{l_i}), & \mbox{if }l \ne 0 \\
a_i \tau^{t_i} \delta^{d_i}, & \mbox{otherwise}
\end{cases}

</math> || <math>a, t, d, l</math>
|-
| gaussian terms || <math>n_i \tau^{t_i} \delta^{d_i} exp[-\alpha_i(\delta - \epsilon_i)^2 - \beta_i(\tau - \gamma_i)^2]</math> || <math> n, t, d, \alpha, \beta, \gamma, \epsilon</math>
|-
| critical terms || <math>n_i \Delta^{b_i} \delta \psi \mbox{ where } \begin{cases}
\Delta = \theta^2 + B_i \left[ \left( \delta - 1 \right)^2 \right]^{a_i} \\
\theta = \left( 1- \tau \right) + A_i \left[ \left( \delta - 1 \right)^2 \right]^{\frac{1}{2 \beta_i}} \\
\psi = exp \left[-C_i \left(\delta-1 \right)^2 - D_i \left( \tau - 1 \right)^2 \right]
\end{cases}</math>
|| <math>n, a, b, \beta, A, B, C, D</math>
|}

These different terms are used in various combinations across a number of high-accuracy publications of thermodynamic property data. Overall, the residual series permits calculation of 'real' reduced Helmholtz energy <math>\phi \left(\tau,\delta \right) = \phi^0 \left(\tau,\delta \right) + \phi^r \left( \tau,\delta \right)</math> and hence the specific Helmholtz energy <math>a = R T \phi \left(\tau,\delta\right)</math>.

From the expression for <math>\phi</math>, we can then derive expressions for <math>p</math>, <math>h</math>, <math>u</math>, <math>s</math> and their partial derivatives with respect to density and temperature. These expressions are summarised in IAPWS-95<ref name=iapws95></ref> as well as by Tillner Roth et al<ref>Tillner-Roth, Harms-Watzenberg and Baehr (1993), "Eine neue Fundamentalgleichung für Ammoniak",
''DKV-Tagungsbericht'', '''20''', 167-181</ref>.

=== Saturated mixture properties ===

The Helmholtz function <math>a \left(\rho,T \right)</math>, given above, applies for all regions outside the saturation region. The saturation region, on the other hand, is not calculated directly from the raw Helmholtz correlation. Instead within the saturation region, the stable equilibrium of phases must be calculated such that the liquid phase vapour phases have equal Gibbs free energy <math>g = a + p / \rho</math>. This requirement is equivalent to the Maxwell equal area rule<ref>http://en.wikipedia.org/wiki/Van_der_Waals_equation</ref><ref name=iapws95></ref><ref>Eubank & Hall (2004), "Equal area rule and algorithm for determining phase compositions", ''AIChE Journal'', '''41''', {{doi|10.1002/aic.690410419}}</ref>. The condition can be expressed as a set of three simultaneous equations in the variables <math>p_{sat}, \rho_f, \rho_g</math>:

:<math>
\begin{align}
p_{sat} & = p \left(\rho_f, T \right) \\
p_{sat} & = p \left(\rho_g, T \right) \\
g\left(\rho_f,T \right) &= g\left(\rho_g,T \right)
\end{align}
</math>

This can be further reduced to :

:<math>
\begin{align}
p_{sat} & = R T \rho_f \left(1 + \delta_f \phi^r_\delta \left(\tau,\delta_f \right) \right) \\
p_{sat} & = R T \rho_g \left(1 + \delta_g \phi^r_\delta \left(\tau,\delta_g, \right) \right) \\
\frac{p_{sat}}{R T} \left( \frac{1}{\rho_g} - \frac{1}{\rho_f} \right) & = \phi \left(\tau, \delta_f \right) - \phi \left(\tau, \delta_g \right)
= \ln \left( \frac{\rho_f}{\rho_g} \right) + \phi^r \left(\tau, \delta_f \right) - \phi^r \left(\tau, \delta_g \right)
\end{align}
</math>

Calculation of the phase equilibrium conditions requires iterative solution of these three equations; one suitable approach is that of Akasaka<ref name=akasaka2008>Akasaka (2008) "A Reliable and Useful Method to Determine the Saturation State from Helmholtz Energy Equations of State", ''Journal of Thermal Science and Technology'', '''3''', 442-451, {{doi|10.1299/jtst.3.442}}</ref>, which first eliminates <math>p_{sat}</math> from the above equations, then iterates only on <math>\rho_f</math> and <math>\rho_g</math>. The approach seems to be robust, with tests currently performed with a sample of five fluids including water, carbon-dioxide and nitrogen. Our code is in {{src|models/johnpye/fprops/sat.c}}.

The Akasaka approach is markedly simpler to implement that the complicated algorithm used in REFPROP (which is explained by Akasaka, and also by Soave<ref>Soave (1986), "Direct calculation of pure-compound vapour pressures through cubic equations of state ", ''Fluid Phase Equilibria'', '''31''', 203-207, {{doi|10.1016/0378-3812(86)90013-0}}</ref>). A limitation of the Soave approach is that it does not converge for temperatures <math>T \gtrapprox 0.99 T_c</math>, and hence requires yet another, even more complicated, algorithm to be implemented for that region (including need for the very tedious-to-calculate third partial derivatives <math>\phi^r_{\delta \delta \delta}</math>!).

=== Saturation Tsat(p) ===

To calculation the saturation temperature as a function of pressure, a different iteration scheme from the above for <math>p_{sat}(T)</math> is needed. <ref>Long X. Nghiem and Yau-Kun Li, 1985, ''Application of the tangent plane criterion to saturation pressure and temperature computations'', Fluid Phase Equilibria, {{doi|10.1016/0378-3812(85)90059-7}}</ref><ref>M Michelson, 1984, ''Saturation point calculations'', Fluid Phase Equilibria, {{doi|10.1016/0378-3812(85)90005-6}}</ref>

At present, we have implemented <tt>fprops_sat_p</tt> in {{src|models/johnpye/fprops/sat.c}} which provides a solution via simple Newton iteration that makes repeated calls to <tt>fprops_sat_T</tt>. The iteration makes use of the Clapeyron equation to calculate the gradients,
:<math>\left(\frac{\partial p}{\partial T} \right)_{sat} = \frac{h_{fg}}{T v_{fg}}</math>
There is probably a more efficient approach, but this is adequate for the moment.

=== Thermodynamic property derivatives ===
{{experimental}}

The IAPWS has made a release<ref>IAPWS, 2008, ''Revised Advisory Note No. 3 Thermodynamic Derivatives from IAPWS Formulation'', http://www.iapws.org</ref> with information about how partial derivatives of thermodynamic properties with respect to other properties can be calculated in general.

FPROPS includes an initial implementation of these derivative calculations in {{src|models/johnpye/fprops/derivs.c}}, but they have not yet been thoroughly tested.

=== Properties in terms of (p,h) ===

{{experimental}}
It seems to be very helpful to have property correlations calculable in terms of the independent variables (p,h). This seems to aid stability of calculation in larger systems, compared to the (v,T) property pair. This would appear to be in part due to the very small, steep subcooled region when using (v,T) coordinates.

An initial implementation of an iterative solver for properties in terms of (p,h) has been implemented for FPROPS in {{src|models/johnpye/fprops/solve_ph.c}}. Currently, it solves for all regions except for pressures below the triple-point pressure. We hope to overcome this problem soon.

=== Properties in terms of (T,x) ===

For convenience some simple functions for calculating properties in terms of (T,x) have been written. The implementation is in {{src|models/johnpye/fprops/solve_Tx.c}}. Any input with x outside [0,1] or T outside [T_t,T_c] will return an error code. Otherwise, the corresponding rho value will be returned such that (T,rho) is equivalent to the desired state.

A python demonstration of this code is in {{src|models/johnpye/fprops/python/solve_Tx.py}}, which gives the following output:

<pre>
john@thunder:~/ascend/models/johnpye/fprops/python$ python solve_Tx.py
solved state
T = 300.000000, x = 0.500000
--> rho = 0.309802, h = 395476.135716, s = 381991.898474, u = 1491.770280

checking reverse solve:
--> x = 0.500000
</pre>

== Testing the code ==

FPROPS includes a suite of self tests for each fluid that has been implemented. Some of the test data comes from the publications from which the correlations have been taken; other test data comes from using the commercial package [http://www.nist.gov/srd/nist23.htm REFPROP] to calculate some sample data points, and comparing the FPROPS output with that data.

To run the FPROPS tests for a given fluid, <tt>cd</tt> to the FPROPS directory (eg <tt>cd ~/ascend/models/johnpye/fprops</tdd>) then run the test script <tt>./test.py ''fluidname''</tt>, for example:

<source lang="a4c">./test.py hydrogen
./test.py nitrogen</source>
''Requires GNU scientific library(libgsl0-dev) to be installed in the system''.

The output will tell you if all calculated values have conformed to expected error margins.

Test code for each fluid is (should be) embedded at the end of the corresponding fluid file, for example {{src|models/johnpye/fprops/fluids/hydrogen.c}}.

During development, some additional testing routines are in the python subdirectory. These include

* <tt>satcvgc.py</tt> to test converge of saturation region routines <tt>fprops_sat_T</tt> and <tt>fprops_sat_p</tt> are working.
* <tt>solve_ph_array</tt> to test convergence of the <tt>fprops_solve_ph</tt> routine, including plotting of regions where the routine is failing.

== Adding new fluids ==

Currently, new fluids must be added by declaring constant data structures in C code.

An example of a fluid declaration is shown in {{src|models/johnpye/fprops/fluids/hydrogen.c}}.

After adding the data structures in "component".c file, a corresponding "component".h is required.

An example of which is shown in {{src|models/johnpye/fprops/fluids/hydrogen.h}}

The new component has to be declared in SConstruct and asc_helmholtz.c.

The data structures which are to be filled are declared in {{src|models/johnpye/fprops/ideal.h}} and {{src|models/johnpye/fprops/helmholtz.h}}.

'''Note''': when adding new fluids it is important to observe that different papers give different 'zero points' for enthalpy and entropy for the substances in question, and the zero points vary from paper to paper. These Helmholtz equations of state can be adjusted for different 'zero points' by adjusting the constant and linear parameters ('<tt>c</tt>' and '<tt>m</tt>') in the IdealData object that is provided in your data structures. The equation to fix these values is

:<math>\frac{\Delta h}{RT} = \tau \Delta \phi_{\tau}^0 = T^{*} \Delta a_2^0</math>

:<math>\frac{\Delta s}{R} = \tau \Delta \phi_{\tau}^0 - \Delta \phi^0 = - \Delta a_1^0</math>

where we assume

:<math>\phi^0(\tau,\delta) = a_1^0 + a_2^0 \tau + \mathrm{other\ terms\ in\ \tau, \delta}</math>

In other words, to correct an offset in ''h'' and ''s'', these formulae tell you the offset to apply to the constant and linear terms in φ0(τ,δ).

== Using within ASCEND ==

To use FPROPS from ASCEND, see the example code in {{src|models/johnpye/fprops/fprops_test.a4c}}. Essentially you must declare a [[DATA]] instance into which you must place the name of the substance for which you wish to calculate properties. Then you can use the functions
* <tt>helmholtz_p</tt>, to calculate p(T,rho)
* <tt>helmholtz_u</tt>, to calculate u(T,rho)
* <tt>helmholtz_h</tt>, to calculate h(T,rho)
* <tt>helmholtz_s</tt>, to calculate s(T,rho)
* <tt>helmholtz_a</tt>, to calculate a(T,rho)
* <tt>helmholtz_cp</tt>, to calculate cp(T,rho)
* <tt>helmholtz_cv</tt>, to calculate cv(T,rho)
* <tt>helmholtz_w</tt>, to calculate speed of sound for given (T,rho)
* <tt>helmholtz_phsx_vT</tt> is also available which returns p, h, s and x in for specified (v,T).
* <tt>helmholtz_Tvsx_ph</tt> returns T, v, s and x for specified (p,h). Recommended for energy system models.

'''Note'''. When solving properties in 'reverse' mode (eg solving for ρ,''T'' when ''p'',''h'' are know), you will get significantly better results by switching the QRSlv solver parameter for 'convergence test' (convopt) to 'RELNOM_SCALE'. This significantly improves ASCEND's ability to solve these problems. Also, use <tt>OPTION iterationlimit 200</tt> for larger models.

A first system model using FPROPS is available in {{src|models/johnpye/rankine_fprops.a4c}}. The key part is
<source lang="a4c">
cd IS_A fluid;
cd.component :== 'water';
(* ...definitions of p, h, T, v, s, x omitted here... *)

calc_ph: helmholtz_Tvsx_ph(
p, h : INPUT;
T, v, s, x : OUTPUT;
cd : DATA
);
</source>

Some details on the implementation of the 'wrapper' code for connecting FPROPS with ASCEND is given in [[writing ASCEND external relations in C]].

== Using from C ==

Using the FPROPS code from C should also be very straightforward; example code is shown in {{src|models/johnpye/fprops/test.c}}.

== Using from Python ==

FPROPS can also be used from the Python language. There are a number of sample programs in {{srcdir|models/johnpye/fprops/python}}. The API is still evolving as we seek the cleanest ways to report errors back to the user, and catch floating-point errors, etc.

== Further work ==
{{task}}

FPROPS is still under development! We aim to implement a few more features including

* <s>add support for '''calculation of the saturation curve''' using Maxwell phase-equilibrium condition</s>
* <s>add iterative solver for properties in terms of (p,h)</s>
* <s>support for Water using IAPWS-95 correlation (partially complete, but needs support for another type of residual function term).</s>
* <s>refactor the 'HelmholtzExpTerm' which is actually a double of 'HelmholtzGausTerm' with epsilon = 1.</s>
* <s>add support for calculation of partial derivatives dp/dT, dp/drho, dh/dT, dh/drho, du/dT, du/drho,</s> ds/dT, ds/drho, da/dT, da/drho <s>to improve convergence of ASCEND models that calculate p, h, u,</s> s, a etc.
* investigate apparent disagreement between cp0 for '''ammonia''' in FPROPS and values from REFPROP (is it consistent with Tillner-Roth?)
* investigate apparent very small discrepancy between REFPROP and IAPWS95 in value of speed of sound near critical point.
* move specification of the '''zero point''' out of IdealData and into HelmholtzData. Third law of thermodynamics? How to avoid correlations with negative ''h'' or ''s'' values?
* implement a '''pre-calculation routine''' where for example coefficients of <math>\phi^0</math> can be prepared?
* implement support for thermophysical properties '''conductivity, viscosity, surface tension,''' and possibly others.
* <s>implement support for calculation of the speed of sound.</s>
* resolve the confusion between T* and T_crit in the data structures. Probably all correlations will be using T_crit -- but is that sure?
* <s>remove p_c from HelmholtzData structure, because that value can be calculated using p(T_c,rho_c).</s>
* add support for solving in terms of (p,h) where p < p_t, the triple point pressure.
* possibly some additional coefficients needs in order to support correlations such as for Methanol<ref>K de Reuck, 1993, ''Methanol, International Thermodynamic Tables of the Fluid State Vol. 12 (1993)'', Blackwell/IUPAC, http://www.iupac.org/objID/Source/sou65427568843800267934799</ref>
* add properties of R-134a (see {{doi|10.1063/1.555958}})

Further down the track we would like to support:

* reading property correlations from a '''database''' (SQLite?) or text file.
* some simpler equations of state such as MBWR or Peng-Robinson.(Assigned to Ankit, see [[PengRobinson EOS in FPROPS]])
* lots more fluids
* '''mixing models''' for multi-phase, multi-component systems (or else incorporate FPROPS into exist code that supports this).
* [http://www.gerg.info/publications/tm/tm15_04.pdf natural gas properties?]
* [http://www.if.uidaho.edu/~vutgikar/Fall2007/Hydrogen/AIR.pdf air properties] {{doi|10.1063/1.1285884}}

We'd be very pleased to be able to collaborate on this work with others; the code has been made deliberately able to stand alone; it has no dependency on any other code from ASCEND, and is suitable for incorporation into other open source programs, subject to the restrictions of the GPL license.

== References ==

<references/>

== Contributors ==

The people who have contributed code and/or implementable advice for FPROPS:
* [[User:Jpye|John Pye]]
* [[User:Kchittur|Krishnan Chittur]]
* HongKe
* [[User:Rshrikanth|Shrikanth Ranganadham ]]
* [[User:Ankitml|Ankit Mittal]]

== See Also ==

* [[Combined-cycle gas turbine]]
* [[Thermodynamics with ASCEND]]
* [[freesteam]]

[[Category:Proposed]]
[[Category:Development]]
[[Category:Documentation]]

PengRobinson EOS in FPROPS

2011-06-02T16:44:52Z

RichardTowers: Added overview

{{task}}
Work on this is went on as a part of GSoC 2010, Project [[User:Ankitml|Ankit]] and continues as part of GSoC 2011, [[User:richardTowers|Richard Towers]]

Comments and suggestions are welcome
==Overview==
The Peng-Robinson EOS is a cubic equation of state in that it contains volume terms to the third power, it is one of several equations of state that can be expressed in the form
:<math>
\begin{align}
P=\frac{RT}{V-b}-\frac{a}{V^2+ubV+wb^2}
\end{align}
</math>
or
:<math>
\begin{align}
Z^3-(1+B^*-uB^*)Z^2+(A^*+wB^{*2}-uB^*-uB^{*2})Z-A^*B^*-wB^{*2}-wB^{*3}=0
\end{align}
</math>
Where
:<math>
\begin{align}
A^*=\frac{aP}{R^2T^2}
\end{align}
</math>
:<math>
\begin{align}
B^*=\frac{bP}{RT}
\end{align}
</math>
In the Peng-Robinson values for <math>u,</math> <math>w</math>, <math>b</math> and <math>a</math> are set as
:<math>
\begin{align}
u=2
\end{align}
</math>
:<math>
\begin{align}
w=-1
\end{align}
</math>
:<math>
\begin{align}
b=\frac{0.7780RT_c}{P_c}
\end{align}
</math>
:<math>
\begin{align}
a=\frac{0.45724R^2T_c^2}{P_c}[1+f\omega(1-T_r^{\frac{1}{2}})]^2
\end{align}
</math>
:<math>
\begin{align}
f\omega=0.37464+1.54226\omega-0.26992\omega^2
\end{align}
</math>
So, for given values of <math>R</math>, <math>T_c</math>, <math>T_r</math>, <math>P_c</math> and <math>\omega</math> we can solve for <math>Z</math>. What next??
==Algorithm==
===Algorithm From Literature===
*Guess a Pressure.
*Find roots of volume using PR-EOS, if roots<3 guess P again.
*Min V is the molar liquid volume, and the max V is vapour molar volume.
*get Zl and Zv.
*Get fugacities of both phases.
*Pnew = Pold*fl/fv

===The current Algorithm===
*Calculate PV data using PR_EOS from 0.001 to 6666 cm3/mol.
*Get the range of Pressure in which volume has 3 roots.
*Give this range as lower and upper bounds to a golden search algorithm, minimizing the difference in fugacities.
*To calculate fugacities a non iterative analytical expression was derived for PR-EOS.

===Issues That Forced to Deviate From Literature===
*Find a non iterative way to solve a cubic Equation for volume. The normal iterative one makes the algorithm very slow, as it is required to solve the volume cubic many number of times to arrive at the solution. So right now generating PV data for a range with a constant increment in V.
*This also helps in guessing the first P in the range of 3 roots, which is required as the first step.
*The golden search algorithm is just experimental over the standard Pnew = Pold*Fl/Fv iteration, which requires a good guess whereas Golden search requires a bracket in which solution lies. It is yet to be tested which one is better.

==Limitations==
===Errors===
*Not working at some temperatures. [It should work on entire range from triple point to Critical Temperature]

[Solution] - Currently trying got find out the reason for this behaviour. - [http://ascendwiki.cheme.cmu.edu/User:Ankitml Ankit ]

*Not predicting Saturation Volumes for Liquids correctly.
[Solution] - Its a problem with Peng Robinson EOS, a modification to PR_EOS was proposed by G. Heyen in the paper, "Liquid and Vapor Properties from a cubic Equation of state", in 2nd International Conference on Phase Equilibria and Fluid Properties, 1980.

===Changes to be done to integrate with ASCEND===
*Data (Pc,Tc,Omega) to be taken from data files and only component name should be required in the code.
*No main function
*ASCEND wrapper
*Code should be in C, remove C++ functions.

=Code=
<source lang="c">
#include <stdio.h>
#include <math.h>
#include <iostream>
using namespace std;

//Global Variables
double Tc,Pc,Omega,R,Tre,b,a,RT,T,P[20000],V[20000],Phil,Phiv,Vl,Vv;
int j;

int noRoots(double Psat); //gives out number of roots (of V) at a particular Pressure
double Pcalc(double T, double V); // Calculates Pressure at Given T and V using PR-EOS
int PhiCalc(double PsatGuess); //Calculates fugacities at a given Pressure and Stores it in global variables
double phiDiff(double Pguess); //Finds fugacity difference at a particular P, uses function PhiCalc and is required for golden search algorithm
double goldSer(double a,double c,double b); //Golden search algorithm, function to be minimized is phiDiff and a is the lower bound, b is upper bound, c is the center.

int main()
{

Tc = 304.1282; // Kelvin
Pc = 73.773; // bar
Omega = 0.22394; // acentric factor
R = 83.14; //bar[cm3]/k/mol
T = 260;
RT = R*T;
Tre = T/Tc;

double p[20000],v[20000];
//following for loop calculates P V data till v=6500cm3/mol and stores it in P,V arrays only if P is within bounds of 60 and -160
j = 0;
for (int i=0;i<20000;i++)
{
v[i] = (i + 0.001)/3;
p[i] = Pcalc(T,v[i]);
if(p[i]<60.0 && p[i]>-160.0)
{
P[j] = p[i];
V[j] = v[i];
j++;
}
}

//finding the bounds for P
double pStart,deltaP;
pStart = 0.01;
deltaP = 1.0;
for(int n = 0;n<3;n++)
{
for(double pp = pStart;pp<60.0;pp=pp+deltaP)
{
int nor;
nor = noRoots(pp);
if (nor==3)
{
pStart = pp - deltaP;
pp = 59.0;
}
}
deltaP = deltaP/10;
}
pStart = pStart + 0.01;

double pEnd;
pEnd = pStart;
deltaP = 1.0;
for(int n = 0;n<2;n++)
{
for(double pp = pEnd;pp<60.0;pp=pp+deltaP)
{
int nor;
nor = noRoots(pp);
if (nor<3)
{
pEnd = pp - deltaP;
pp = 5000;
}
}
deltaP = deltaP/10;
}

int sandbox;
double Pa,Pb,Pc,sol,phi,resphi;
phi = (1 + sqrt(5))/2;
resphi = 2 - phi;
Pa = pStart;
Pb = pEnd;
Pc = (Pb - Pa)*resphi + Pa;
sol = goldSer(Pa,Pc,Pb);
sandbox=PhiCalc(sol);
cout<<"Molar Volume (L) = "<<Vl<<" cm3/mol"<<'\n';
cout<<"Molar Volume (V) = "<<Vv<<" cm3/mol"<<'\n';
cout<<"Difference in fugacities of vapour and liquid = "<<fabs(Phil-Phiv)<<'\n';
cout<<T<<'\t'<<sol<<'\t'<<Vl<<'\t'<<Vv<<'\t'<<fabs(Phil-Phiv)<<'\n';

return 0;
}

int noRoots(double Psat)
{
double Vroot[3];
Vroot[0] = -99; Vroot[1] = -99; Vroot[2] = -99;
int rootCount = 0;
for (int i = 0; i < j-1;i++)
{
if((Psat<=P[i+1] && Psat>=P[i]) || (Psat>=P[i+1] && Psat<=P[i]))
{
Vroot[rootCount] = V[i]+(Psat-P[i])*(V[i+1]-V[i])/(P[i+1]-P[i]);
rootCount++;
}
}
return rootCount;
}

double Pcalc(double T, double V)
{
double P,m,tmp;
b = 0.0778*R*Tc/Pc;
m = 0.37464+1.54226*Omega-0.26992*pow(Omega,2);
tmp = 1+m*(1-sqrt(Tre));
a = 0.45724*R*R*Tc*(Tc/Pc)*pow(tmp,2);
P = R*T/(V-b) - a/(V*(V+b)+b*(V-b));
return P;
}

int PhiCalc(double PsatGuess)
{ double Vroot[3],A,B;
B = PsatGuess*b/RT;
A = a*PsatGuess/pow(RT,2);
Vroot[0] = -99; Vroot[1] = -99; Vroot[2] = -99;
int rootCount = 0;
for (int i = 0; i < j-1;i++)
{
if((PsatGuess<=P[i+1] && PsatGuess>=P[i]) || (PsatGuess>=P[i+1] && PsatGuess<=P[i]))
{
Vroot[rootCount] =V[i]+(PsatGuess-P[i])*(V[i+1]-V[i])/(P[i+1]-P[i]);
rootCount++;
}
}

double Zv,Zl;
double term_a,term_b,term_c;

Vl = Vroot[0]; //liquid volume is the smaller root
Vv = Vroot[2]; // vapour volume is the largest one

Zl = PsatGuess*Vl/(R*T); //the corresponding Z
Zv = PsatGuess*Vv/(R*T);

term_a = (1 + sqrt(2))*B;
term_b = (1 - sqrt(2))*B;
term_c = 2*sqrt(2)*B;

Phil = (Zl-1) - log(Zl-B) - A/term_c*log((Zl+term_a)/(Zl+term_b));
Phiv = (Zv-1) - log(Zv-B) - A/term_c*log((Zv+term_a)/(Zv+term_b));
return 0;
}

double phiDiff(double Pguess)
{
double phiD;
int sandbox;
sandbox = PhiCalc(Pguess);
phiD = fabs(Phil - Phiv);
return phiD;
}

double goldSer(double a,double c,double b)
{
double d,phi,resphi;
phi = (1 + sqrt(5))/2;
resphi = 2 - phi;
if (fabs(a-b)<0.000001)
return ((a+b)/2);

d = c + resphi*(b - c);

if (phiDiff(d)<phiDiff(c))
return goldSer(c,d,b);
else
return goldSer(d,c,a);
}

</source>
==Possible Improvements in the code==

* Maybe this is of interest: http://pubs.acs.org/doi/abs/10.1021/ed066p54.2 ? [[User:Jpye|Jpye]] 06:39, 5 August 2010 (UTC)

==Comparisons==

[[Category:Development]]

FPROPS

2011-06-02T16:27:20Z

RichardTowers: /* Implementation - As much as I understand on peng-robinson */

<div style="float:right;border:solid 1pt green;background-color=#EEFFEE;width:18em;padding:12px">
'''Fluids supported by FPROPS'''

{{fpropsfluid|ammonia}}, {{fpropsfluid|nitrogen}}, {{fpropsfluid|hydrogen}}, {{fpropsfluid|water}}, {{fpropsfluid|carbondioxide}}, {{fpropsfluid|methane}}, {{fpropsfluid|carbonmonoxide}}, {{fpropsfluid|ethanol}}, {{fpropsfluid|acetone}}, {{fpropsfluid|carbonylsulfide}}, {{fpropsfluid|decane}}, {{fpropsfluid|hydrogensulfide}}, {{fpropsfluid|isohexane}}, {{fpropsfluid|isopentane}}, {{fpropsfluid|krypton}}, {{fpropsfluid|neopentane}}, {{fpropsfluid|nitrousoxide}}, {{fpropsfluid|nonane}}, {{fpropsfluid|sulfurdioxide}}, {{fpropsfluid|toluene}}, {{fpropsfluid|xenon}}, {{fpropsfluid|butane}}, {{fpropsfluid|butene}}, {{fpropsfluid|cisbutene}}, {{fpropsfluid|isobutene}}, {{fpropsfluid|transbutene}}, {{fpropsfluid|dimethylether}}, {{fpropsfluid|ethane}}, {{fpropsfluid|parahydrogen}}, {{fpropsfluid|isobutane}}, {{fpropsfluid|r41}}, {{fpropsfluid|r116}}, {{fpropsfluid|r141b}}, {{fpropsfluid|r142b}}, {{fpropsfluid|r218}}, {{fpropsfluid|r245fa}}

(in svn, at r3042)
</div>
'''FPROPS''' is a free open-source C-based library for high-accuracy evaluation of thermodynamic properties for a number of pure substances. It makes use of published data for the Helmholtz fundamental equation for those substances. It has been developed by [[User:Jpye|John Pye]] and [[#Contributors|others]], and will happily function as standalone code, but is also provided with [[external library]] code for ASCEND so that it can be used to access these accurate property correlations from within a [[MODEL]].

Currently FPROPS supports calculation of the properties of the pure substances shown on the right. The properties that can be calculated are internal energy <math>u</math>, entropy <math>s</math>, pressure <math>p</math>, enthalpy <math>h</math> and Helmholtz energy <math>a</math>, as well as various partial derivatives of these with respect to temperature and density.

FPROPS reproduces a limited subset of the functionality of commercial programs such as [http://www.nist.gov/srd/nist23.htm REFPROP], [http://gibbs.mech.kyushu-u.ac.jp/~akasaka/propath_man/ PROPATH], EES, [http://www.ruhr-uni-bochum.de/thermo/Software/Seiten/Fluidcal-eng.htm FLUIDCAL], [[freesteam]], SteamTab, and others, but is free open-source software, licensed under the [http://www.gnu.org/licenses/gpl.html GPL]. Contributions are most welcome!

Enhancement to FPROPS feature set and list of supported fluids has been going on as part of ASCEND's involvement in [[GSOC2010]].

FPROPS is included with ASCEND as of version 0.9.5.116, or you can browse the code at {{srcdir|models/johnpye/fprops/}} or access it [[VersionManagement|via subversion]] (code is evolving rapidly, as of Aug 2010).

== Implementation ==

The calculation routines implement calculation of reduced Helmholtz energy <math>\phi = a / R T</math> as a function of reduced density <math>\delta = \rho / \rho_c</math> and ''inverse'' reduced temperature <math>\tau = T_c / T</math>, by dividing it into ideal <math>\phi^0 \left(\tau,\delta\right)</math> and 'real' or 'residual' <math>\phi^r \left(\tau,\delta \right)</math> parts, as described in IAPWS-95<ref name=iapws95>http://www.iapws.org/relguide/IAPWS95-Rev.pdf</ref>.

=== Ideal part ===

Calculation of the '''ideal part''' of the reduced Helmholtz energy is derived from the expression for the zero-pressure limit of reduced specific heat capacity at constant pressure, <math>c_p^0 / R</math>, where <math>R</math> is the specific gas constant. This quantity <math>{c_p^0}(T)/R</math> can be expressed as a series composed of two different types of terms:

{| border="1" cellpadding="3" cellspacing="0"
! type !! expression !! correlation constants
|-
| power terms || <math>c_i T^{t_i}</math> || <math>c, t</math>
|-
| exponential terms (also called 'Einstein' terms<ref>Lemmon, E.W. and Span, R.,
2006, ''Short Fundamental Equations of State for 20 Industrial Fluids'', J. Chem. Eng. Data, '''51''', 785-850, {{doi|10.1021/je050186n}}</ref>) || <math>\frac{b_i x_i^2 exp(-x_i)}{[1-exp(-x_i)]^2}</math> where <math>x_i = \frac{\beta_i}{T}</math> || <math>b, \beta</math>
|}

An expression for calculating the ideal component of Helmholtz energy <math>a^0 \left(T , \rho \right)</math> from <math>c_p^0</math> is given by Span et al<ref>Span & Wagner (1996), "A new equation of state for carbon dioxide covering from the triple point temperature to 1100 K at pressures up to 800 MPa" ''J. Phys. Chem. Ref. Data'', '''25''' p 1509 ff, http://link.aip.org/link/?jpr/25/1509%26agg=NIST, {{doi|10.1063/1.555991}}</ref>:

:<math>\frac{a^0}{RT} = \phi^0 = \frac{h_0^0 \tau}{R T_c} - \frac{s_0^0}{R} - 1 + \ln {\frac{\delta / \delta_0}{\tau / \tau_0}} - \frac{\tau}{R} \int_{\tau_0}^{\tau}{\frac{c_p^0}{\tau^2}d\tau} + \frac{1}{R} \int_{\tau_0}^{\tau}{\frac{c_p^0}{\tau} d \tau}</math>

where the '''reduced temperature''' is <math>\tau = \frac{T^{*}}{T}</math> and the '''reduced density''' is <math>\delta = \frac{\rho}{\rho^{*}}</math>.

On the other hand, using the relations for the Helmholtz fundamental equation, one can see that

:<math>\frac{c_p^0}{R} = 1 -\tau^2 \phi^0_{\tau \tau}</math>

so coefficients of <math>c_p^0</math> can be calculated from coefficients of <math>\phi^0</math> (providing, we assume, that the fundamental equation has smooth first and second (and possibly third) derivatives, and that when terms of <math>{c_p^0}(T)</math> are integrated they don't 'interact'). One can go the other way, and determine <math>\phi^0</math> from <math>c_p^0</math>, with the exception of the integration constants, which are, in that case, determined using specified values of enthalpy <math>h^0_{ref}</math> and entropy <math>s^0_{ref}</math> at a reference state <math>\left(T_{ref},\rho_{ref} \right)</math>

=== Residual part ===

For the '''residual part''' of the reduced Helmholtz energy, FPROPS currently supports three different kinds of terms:

{| border="1" cellpadding="3" cellspacing="0"
! type !! expression !! correlation constants
|-
| power terms || <math>

\begin{cases}
a_i \tau^{t_i} \delta^{d_i} exp(-\delta^{l_i}), & \mbox{if }l \ne 0 \\
a_i \tau^{t_i} \delta^{d_i}, & \mbox{otherwise}
\end{cases}

</math> || <math>a, t, d, l</math>
|-
| gaussian terms || <math>n_i \tau^{t_i} \delta^{d_i} exp[-\alpha_i(\delta - \epsilon_i)^2 - \beta_i(\tau - \gamma_i)^2]</math> || <math> n, t, d, \alpha, \beta, \gamma, \epsilon</math>
|-
| critical terms || <math>n_i \Delta^{b_i} \delta \psi \mbox{ where } \begin{cases}
\Delta = \theta^2 + B_i \left[ \left( \delta - 1 \right)^2 \right]^{a_i} \\
\theta = \left( 1- \tau \right) + A_i \left[ \left( \delta - 1 \right)^2 \right]^{\frac{1}{2 \beta_i}} \\
\psi = exp \left[-C_i \left(\delta-1 \right)^2 - D_i \left( \tau - 1 \right)^2 \right]
\end{cases}</math>
|| <math>n, a, b, \beta, A, B, C, D</math>
|}

These different terms are used in various combinations across a number of high-accuracy publications of thermodynamic property data. Overall, the residual series permits calculation of 'real' reduced Helmholtz energy <math>\phi \left(\tau,\delta \right) = \phi^0 \left(\tau,\delta \right) + \phi^r \left( \tau,\delta \right)</math> and hence the specific Helmholtz energy <math>a = R T \phi \left(\tau,\delta\right)</math>.

From the expression for <math>\phi</math>, we can then derive expressions for <math>p</math>, <math>h</math>, <math>u</math>, <math>s</math> and their partial derivatives with respect to density and temperature. These expressions are summarised in IAPWS-95<ref name=iapws95></ref> as well as by Tillner Roth et al<ref>Tillner-Roth, Harms-Watzenberg and Baehr (1993), "Eine neue Fundamentalgleichung für Ammoniak",
''DKV-Tagungsbericht'', '''20''', 167-181</ref>.

=== Saturated mixture properties ===

The Helmholtz function <math>a \left(\rho,T \right)</math>, given above, applies for all regions outside the saturation region. The saturation region, on the other hand, is not calculated directly from the raw Helmholtz correlation. Instead within the saturation region, the stable equilibrium of phases must be calculated such that the liquid phase vapour phases have equal Gibbs free energy <math>g = a + p / \rho</math>. This requirement is equivalent to the Maxwell equal area rule<ref>http://en.wikipedia.org/wiki/Van_der_Waals_equation</ref><ref name=iapws95></ref><ref>Eubank & Hall (2004), "Equal area rule and algorithm for determining phase compositions", ''AIChE Journal'', '''41''', {{doi|10.1002/aic.690410419}}</ref>. The condition can be expressed as a set of three simultaneous equations in the variables <math>p_{sat}, \rho_f, \rho_g</math>:

:<math>
\begin{align}
p_{sat} & = p \left(\rho_f, T \right) \\
p_{sat} & = p \left(\rho_g, T \right) \\
g\left(\rho_f,T \right) &= g\left(\rho_g,T \right)
\end{align}
</math>

This can be further reduced to :

:<math>
\begin{align}
p_{sat} & = R T \rho_f \left(1 + \delta_f \phi^r_\delta \left(\tau,\delta_f \right) \right) \\
p_{sat} & = R T \rho_g \left(1 + \delta_g \phi^r_\delta \left(\tau,\delta_g, \right) \right) \\
\frac{p_{sat}}{R T} \left( \frac{1}{\rho_g} - \frac{1}{\rho_f} \right) & = \phi \left(\tau, \delta_f \right) - \phi \left(\tau, \delta_g \right)
= \ln \left( \frac{\rho_f}{\rho_g} \right) + \phi^r \left(\tau, \delta_f \right) - \phi^r \left(\tau, \delta_g \right)
\end{align}
</math>

Calculation of the phase equilibrium conditions requires iterative solution of these three equations; one suitable approach is that of Akasaka<ref name=akasaka2008>Akasaka (2008) "A Reliable and Useful Method to Determine the Saturation State from Helmholtz Energy Equations of State", ''Journal of Thermal Science and Technology'', '''3''', 442-451, {{doi|10.1299/jtst.3.442}}</ref>, which first eliminates <math>p_{sat}</math> from the above equations, then iterates only on <math>\rho_f</math> and <math>\rho_g</math>. The approach seems to be robust, with tests currently performed with a sample of five fluids including water, carbon-dioxide and nitrogen. Our code is in {{src|models/johnpye/fprops/sat.c}}.

The Akasaka approach is markedly simpler to implement that the complicated algorithm used in REFPROP (which is explained by Akasaka, and also by Soave<ref>Soave (1986), "Direct calculation of pure-compound vapour pressures through cubic equations of state ", ''Fluid Phase Equilibria'', '''31''', 203-207, {{doi|10.1016/0378-3812(86)90013-0}}</ref>). A limitation of the Soave approach is that it does not converge for temperatures <math>T \gtrapprox 0.99 T_c</math>, and hence requires yet another, even more complicated, algorithm to be implemented for that region (including need for the very tedious-to-calculate third partial derivatives <math>\phi^r_{\delta \delta \delta}</math>!).

=== Saturation Tsat(p) ===

To calculation the saturation temperature as a function of pressure, a different iteration scheme from the above for <math>p_{sat}(T)</math> is needed. <ref>Long X. Nghiem and Yau-Kun Li, 1985, ''Application of the tangent plane criterion to saturation pressure and temperature computations'', Fluid Phase Equilibria, {{doi|10.1016/0378-3812(85)90059-7}}</ref><ref>M Michelson, 1984, ''Saturation point calculations'', Fluid Phase Equilibria, {{doi|10.1016/0378-3812(85)90005-6}}</ref>

At present, we have implemented <tt>fprops_sat_p</tt> in {{src|models/johnpye/fprops/sat.c}} which provides a solution via simple Newton iteration that makes repeated calls to <tt>fprops_sat_T</tt>. The iteration makes use of the Clapeyron equation to calculate the gradients,
:<math>\left(\frac{\partial p}{\partial T} \right)_{sat} = \frac{h_{fg}}{T v_{fg}}</math>
There is probably a more efficient approach, but this is adequate for the moment.

=== Thermodynamic property derivatives ===
{{experimental}}

The IAPWS has made a release<ref>IAPWS, 2008, ''Revised Advisory Note No. 3 Thermodynamic Derivatives from IAPWS Formulation'', http://www.iapws.org</ref> with information about how partial derivatives of thermodynamic properties with respect to other properties can be calculated in general.

FPROPS includes an initial implementation of these derivative calculations in {{src|models/johnpye/fprops/derivs.c}}, but they have not yet been thoroughly tested.

=== Properties in terms of (p,h) ===

{{experimental}}
It seems to be very helpful to have property correlations calculable in terms of the independent variables (p,h). This seems to aid stability of calculation in larger systems, compared to the (v,T) property pair. This would appear to be in part due to the very small, steep subcooled region when using (v,T) coordinates.

An initial implementation of an iterative solver for properties in terms of (p,h) has been implemented for FPROPS in {{src|models/johnpye/fprops/solve_ph.c}}. Currently, it solves for all regions except for pressures below the triple-point pressure. We hope to overcome this problem soon.

=== Properties in terms of (T,x) ===

For convenience some simple functions for calculating properties in terms of (T,x) have been written. The implementation is in {{src|models/johnpye/fprops/solve_Tx.c}}. Any input with x outside [0,1] or T outside [T_t,T_c] will return an error code. Otherwise, the corresponding rho value will be returned such that (T,rho) is equivalent to the desired state.

A python demonstration of this code is in {{src|models/johnpye/fprops/python/solve_Tx.py}}, which gives the following output:

<pre>
john@thunder:~/ascend/models/johnpye/fprops/python$ python solve_Tx.py
solved state
T = 300.000000, x = 0.500000
--> rho = 0.309802, h = 395476.135716, s = 381991.898474, u = 1491.770280

checking reverse solve:
--> x = 0.500000
</pre>

=== Peng-Robinson Equation of State ===
NOT YET IMPLEMENTED
{{experimental}}
The Peng-Robinson EOS is a cubic equation of state in that it contains volume terms to the third power, it is one of several equations of state that can be expressed in the form
:<math>
\begin{align}
P=\frac{RT}{V-b}-\frac{a}{V^2+ubV+wb^2}
\end{align}
</math>
or
:<math>
\begin{align}
Z^3-(1+B^*-uB^*)Z^2+(A^*+wB^{*2}-uB^*-uB^{*2})Z-A^*B^*-wB^{*2}-wB^{*3}=0
\end{align}
</math>
Where
:<math>
\begin{align}
A^*=\frac{aP}{R^2T^2}
\end{align}
</math>
:<math>
\begin{align}
B^*=\frac{bP}{RT}
\end{align}
</math>
In the Peng-Robinson values for <math>u,</math> <math>w</math>, <math>b</math> and <math>a</math> are set as
:<math>
\begin{align}
u=2
\end{align}
</math>
:<math>
\begin{align}
w=-1
\end{align}
</math>
:<math>
\begin{align}
b=\frac{0.7780RT_c}{P_c}
\end{align}
</math>
:<math>
\begin{align}
a=\frac{0.45724R^2T_c^2}{P_c}[1+f\omega(1-T_r^{\frac{1}{2}})]^2
\end{align}
</math>
:<math>
\begin{align}
f\omega=0.37464+1.54226\omega-0.26992\omega^2
\end{align}
</math>
So, for given values of <math>R</math>, <math>T_c</math>, <math>T_r</math>, <math>P_c</math> and <math>\omega</math> we can solve for <math>Z</math>. What next??

== Testing the code ==

FPROPS includes a suite of self tests for each fluid that has been implemented. Some of the test data comes from the publications from which the correlations have been taken; other test data comes from using the commercial package [http://www.nist.gov/srd/nist23.htm REFPROP] to calculate some sample data points, and comparing the FPROPS output with that data.

To run the FPROPS tests for a given fluid, <tt>cd</tt> to the FPROPS directory (eg <tt>cd ~/ascend/models/johnpye/fprops</tdd>) then run the test script <tt>./test.py ''fluidname''</tt>, for example:

<source lang="a4c">./test.py hydrogen
./test.py nitrogen</source>
''Requires GNU scientific library(libgsl0-dev) to be installed in the system''.

The output will tell you if all calculated values have conformed to expected error margins.

Test code for each fluid is (should be) embedded at the end of the corresponding fluid file, for example {{src|models/johnpye/fprops/fluids/hydrogen.c}}.

During development, some additional testing routines are in the python subdirectory. These include

* <tt>satcvgc.py</tt> to test converge of saturation region routines <tt>fprops_sat_T</tt> and <tt>fprops_sat_p</tt> are working.
* <tt>solve_ph_array</tt> to test convergence of the <tt>fprops_solve_ph</tt> routine, including plotting of regions where the routine is failing.

== Adding new fluids ==

Currently, new fluids must be added by declaring constant data structures in C code.

An example of a fluid declaration is shown in {{src|models/johnpye/fprops/fluids/hydrogen.c}}.

After adding the data structures in "component".c file, a corresponding "component".h is required.

An example of which is shown in {{src|models/johnpye/fprops/fluids/hydrogen.h}}

The new component has to be declared in SConstruct and asc_helmholtz.c.

The data structures which are to be filled are declared in {{src|models/johnpye/fprops/ideal.h}} and {{src|models/johnpye/fprops/helmholtz.h}}.

'''Note''': when adding new fluids it is important to observe that different papers give different 'zero points' for enthalpy and entropy for the substances in question, and the zero points vary from paper to paper. These Helmholtz equations of state can be adjusted for different 'zero points' by adjusting the constant and linear parameters ('<tt>c</tt>' and '<tt>m</tt>') in the IdealData object that is provided in your data structures. The equation to fix these values is

:<math>\frac{\Delta h}{RT} = \tau \Delta \phi_{\tau}^0 = T^{*} \Delta a_2^0</math>

:<math>\frac{\Delta s}{R} = \tau \Delta \phi_{\tau}^0 - \Delta \phi^0 = - \Delta a_1^0</math>

where we assume

:<math>\phi^0(\tau,\delta) = a_1^0 + a_2^0 \tau + \mathrm{other\ terms\ in\ \tau, \delta}</math>

In other words, to correct an offset in ''h'' and ''s'', these formulae tell you the offset to apply to the constant and linear terms in φ0(τ,δ).

== Using within ASCEND ==

To use FPROPS from ASCEND, see the example code in {{src|models/johnpye/fprops/fprops_test.a4c}}. Essentially you must declare a [[DATA]] instance into which you must place the name of the substance for which you wish to calculate properties. Then you can use the functions
* <tt>helmholtz_p</tt>, to calculate p(T,rho)
* <tt>helmholtz_u</tt>, to calculate u(T,rho)
* <tt>helmholtz_h</tt>, to calculate h(T,rho)
* <tt>helmholtz_s</tt>, to calculate s(T,rho)
* <tt>helmholtz_a</tt>, to calculate a(T,rho)
* <tt>helmholtz_cp</tt>, to calculate cp(T,rho)
* <tt>helmholtz_cv</tt>, to calculate cv(T,rho)
* <tt>helmholtz_w</tt>, to calculate speed of sound for given (T,rho)
* <tt>helmholtz_phsx_vT</tt> is also available which returns p, h, s and x in for specified (v,T).
* <tt>helmholtz_Tvsx_ph</tt> returns T, v, s and x for specified (p,h). Recommended for energy system models.

'''Note'''. When solving properties in 'reverse' mode (eg solving for ρ,''T'' when ''p'',''h'' are know), you will get significantly better results by switching the QRSlv solver parameter for 'convergence test' (convopt) to 'RELNOM_SCALE'. This significantly improves ASCEND's ability to solve these problems. Also, use <tt>OPTION iterationlimit 200</tt> for larger models.

A first system model using FPROPS is available in {{src|models/johnpye/rankine_fprops.a4c}}. The key part is
<source lang="a4c">
cd IS_A fluid;
cd.component :== 'water';
(* ...definitions of p, h, T, v, s, x omitted here... *)

calc_ph: helmholtz_Tvsx_ph(
p, h : INPUT;
T, v, s, x : OUTPUT;
cd : DATA
);
</source>

Some details on the implementation of the 'wrapper' code for connecting FPROPS with ASCEND is given in [[writing ASCEND external relations in C]].

== Using from C ==

Using the FPROPS code from C should also be very straightforward; example code is shown in {{src|models/johnpye/fprops/test.c}}.

== Using from Python ==

FPROPS can also be used from the Python language. There are a number of sample programs in {{srcdir|models/johnpye/fprops/python}}. The API is still evolving as we seek the cleanest ways to report errors back to the user, and catch floating-point errors, etc.

== Further work ==
{{task}}

FPROPS is still under development! We aim to implement a few more features including

* <s>add support for '''calculation of the saturation curve''' using Maxwell phase-equilibrium condition</s>
* <s>add iterative solver for properties in terms of (p,h)</s>
* <s>support for Water using IAPWS-95 correlation (partially complete, but needs support for another type of residual function term).</s>
* <s>refactor the 'HelmholtzExpTerm' which is actually a double of 'HelmholtzGausTerm' with epsilon = 1.</s>
* <s>add support for calculation of partial derivatives dp/dT, dp/drho, dh/dT, dh/drho, du/dT, du/drho,</s> ds/dT, ds/drho, da/dT, da/drho <s>to improve convergence of ASCEND models that calculate p, h, u,</s> s, a etc.
* investigate apparent disagreement between cp0 for '''ammonia''' in FPROPS and values from REFPROP (is it consistent with Tillner-Roth?)
* investigate apparent very small discrepancy between REFPROP and IAPWS95 in value of speed of sound near critical point.
* move specification of the '''zero point''' out of IdealData and into HelmholtzData. Third law of thermodynamics? How to avoid correlations with negative ''h'' or ''s'' values?
* implement a '''pre-calculation routine''' where for example coefficients of <math>\phi^0</math> can be prepared?
* implement support for thermophysical properties '''conductivity, viscosity, surface tension,''' and possibly others.
* <s>implement support for calculation of the speed of sound.</s>
* resolve the confusion between T* and T_crit in the data structures. Probably all correlations will be using T_crit -- but is that sure?
* <s>remove p_c from HelmholtzData structure, because that value can be calculated using p(T_c,rho_c).</s>
* add support for solving in terms of (p,h) where p < p_t, the triple point pressure.
* possibly some additional coefficients needs in order to support correlations such as for Methanol<ref>K de Reuck, 1993, ''Methanol, International Thermodynamic Tables of the Fluid State Vol. 12 (1993)'', Blackwell/IUPAC, http://www.iupac.org/objID/Source/sou65427568843800267934799</ref>
* add properties of R-134a (see {{doi|10.1063/1.555958}})

Further down the track we would like to support:

* reading property correlations from a '''database''' (SQLite?) or text file.
* some simpler equations of state such as MBWR or Peng-Robinson.(Assigned to Ankit, see [[PengRobinson EOS in FPROPS]])
* lots more fluids
* '''mixing models''' for multi-phase, multi-component systems (or else incorporate FPROPS into exist code that supports this).
* [http://www.gerg.info/publications/tm/tm15_04.pdf natural gas properties?]
* [http://www.if.uidaho.edu/~vutgikar/Fall2007/Hydrogen/AIR.pdf air properties] {{doi|10.1063/1.1285884}}

We'd be very pleased to be able to collaborate on this work with others; the code has been made deliberately able to stand alone; it has no dependency on any other code from ASCEND, and is suitable for incorporation into other open source programs, subject to the restrictions of the GPL license.

== References ==

<references/>

== Contributors ==

The people who have contributed code and/or implementable advice for FPROPS:
* [[User:Jpye|John Pye]]
* [[User:Kchittur|Krishnan Chittur]]
* HongKe
* [[User:Rshrikanth|Shrikanth Ranganadham ]]
* [[User:Ankitml|Ankit Mittal]]

== See Also ==

* [[Combined-cycle gas turbine]]
* [[Thermodynamics with ASCEND]]
* [[freesteam]]

[[Category:Proposed]]
[[Category:Development]]
[[Category:Documentation]]

User:RichardTowers

2011-06-02T15:19:00Z

RichardTowers: /* Separating Correlation Coefficients */

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

== Initial Thoughts ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* [[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/hydrogen.xml?view=markup hydrogen.xml]. Note that the constant term is specified as a multiple of R as described above.

====Parser====
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in the (accidentally misspelt) [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/parcer.c?view=markup parcer.c].

== Equations of State ==
Firstly I'll be looking at the Peng-Robinson cubic EOS, possibly adding some other equations in the same family (van der Waals, Redlich-Kwon and Soave for example). See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup pengrobinson.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

[[Category:GSOC2011]]

User:RichardTowers

2011-06-02T15:17:53Z

RichardTowers: /* Equations of State - link to source*/

'''Richard Towers''' is a GSOC2011 student (Masters of Engineering, Mechanical) from The University of Durham (UK), working on improvements to [[FPROPS]].

== Initial Thoughts ==
A brief summary of what I hope to achieve over the summer. These points largely follow [http://kh3dev.googlecode.com/files/FPROPSRichardTowers.pdf my GSOC application], feel free to ridicule my youthful ambition.
* [[#Testing|All current fluids tested and all discrepancies discovered]]
* Squashed some bugs!
* [[#Improvements to documentation|Improvements to documentation]]
* [[#Separating Correlation Coefficients|Separated correlation coefficients from program code, load at run-time]]
* [[#Equations of State|Added support for one other eqn. of state and tested successfully]]
* Increased confirmed fluid support to 50 fluids
* Added support for a0 (p, h) where p < pt
* Added support for two more eqns. of state, tested successfully
* Added support for pseudo-pure fluids
* Increased confirmed fluid support to 70 fluids
* Added support for at least one mixture

== Testing ==
Need to find ''correct'' data for comparison. Working version of REFPROP? Literature?
Inconsistencies need to be investigated and hopefully fixed.
== Improvements to documentation ==
As part of the build up to starting work I've been reading through the LyX generated help file that comes with ASCEND, Having just finished a dissertation written in LyX and LaTeX/pgf/tikz I could probably help significantly with the general appearance of this document, for example:
{|
| [[File:OldAsendTypesDiagram.png|thumb|alt=An old spider diagram detailing ASCEND types|Old Types Diagram]]
| [[File:AscendTypes.png|thumb|alt=A new spider diagram detailing ASCEND types|New Types Diagram]]
| [[File:OldCylinder.png|thumb|alt=An old diagram showing a thin walled cylinder|Old Cylinder Diagram]]
| [[File:Cylinder.png|thumb|alt=A new diagram showing a thin walled cylinder|New Cylinder Diagram]]
|}

== Separating Correlation Coefficients ==
Coefficients should be stored in human readable files, not as C source. The plan is to create an XML structure for these files and a function to parse the files, loading fluid information at runtime. John suggests using RelaxNG as the schema, I'm not sure whether or not ASCEND already has a preferred cross platform XML parser, to begin with I'll use GNOME's libxml.
====Relax NG Grammar====
Element names identify the property in question and attributes identify values. The advantage of using attributes instead of node text is that we can specify different attributes (for the same property) that are treated differently, for example: it is sometimes useful to specify the constant ideal term as a multiple of the specific gas constant instead of as an absolute value. [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/fluidSchema.rng?view=markup fluidSchema.rng]

====Example XML Fluid File====
As an example a fluid file for Hydrogen can be found in [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/hydrogen.xml?view=markup hydrogen.xml]. Note that the constant term is specified as a multiple of R as described above.

===Parser===
The minimum requirements of the parser are quite simple, however it would be nice not to have to worry about arranging xml elements in a specific order and some variables are easier to specify as multiples of some other variable. The beginnings of a competent parser are found in the (accidentally misspelt) [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/fluids/parcer.c?view=markup parcer.c].

== Equations of State ==
Firstly I'll be looking at the Peng-Robinson cubic EOS, possibly adding some other equations in the same family (van der Waals, Redlich-Kwon and Soave for example). See [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.c?view=markup pengrobinson.c] and [http://code.ascend4.org/viewvc/code/branches/richard/models/johnpye/fprops/pengrobinson.h?view=markup pengrobinson.h] for more.
Later an attempt might be made at implementing Lee and Kesler's modified Benedict-Webb-Rubin EOS, but this is another job for another day...

[[Category:GSOC2011]]