Hi Mark I had a little look at your page, and was looking up the formulae in the related references. Thanks for this!
I found that there's a later publication (2005?) from some of the authors with supplementary material including a 1000-species database as a word file attached to the paper. http://dx.doi.org/10.1016/j.fluid.2004.11.002 (appendix B) If that's useful data, then we can work on converting into C code or a data file or whatever. About the implementation questions... where exactly the data sits or how it's loaded isn't a big problem, I think. I am more thinking about how the calculated species and mixture property data interfaces with ASCEND. There are going to be various options about how many equations are buried in the ASCEND 'black box', and how many equations remain in ASCEND code. I think it would be quite useful to implement a complete solution in pure C to start with, and then to figure out the ASCEND interfacing later, but probably I should read more of your wiki page and the related references in order to understand better. I'll get back to soon, hopefully. Cheers JP On 06/01/16 02:22, [email protected] wrote: > Hi John, > I created a page describing the PSRK model: > http://ascend4.org/Predictive_Soave-Redlich-Kwong_%28PSRK%29 > More explanatory text to come. > > I've been digging through the FPROPS, densemtx, parser, ctoxml and > pengrob C code. > > The main problem I've got is that the modified UNIFAC method relies on > external data provided by the UNIFAC consortium, meaning I have to set > up a separate data file (in C data structures or XML or JSON or > somehow else) with all the values for the main group binary > interaction parameters and the volume and surface area parameters for > all the subgroups. > > The actual PSRK model is set up in Ascend where the components which > make up the mixture, the PSRK equations and physical properties (T_C, > P_C, acentric factor) are defined. > > Thus, a way has to be found for retrieving the parameters from the > external datafile for the wanted main and subgroups (which the > components are divided into), to process the data (dense matrices, > transformation, multiplication via BLAS/LAPACK) and then make it > available for the Ascend model (maybe by using external relations?). > The data has only to be retrieved once by the Ascend model...no > multiple calls while iterating. > > How do you suggest to implement this? FPROPS seems for me not the way > to go because there is still need of an external datafile and for > modelling vapour-liquid equilibria PSRK method has to go through an > iteration cycle. > > I was thinking of a XML or JSON datafile. Query the wanted data and > manipulate the data with C and BLAS/LAPACK and then provide the data > to the Acend model via an external relation (INPUT: components list, > OUTPUT: UNIFAC data stored in two dimensional matrices). I'm not sure > about if it's possible to pass matrices with an external relation... > > Hope you understand what I'm trying to explain and maybe you have a > very elegant idea to solve this problem. I don't want to start coding > before I really know how to implement it. > > Cheers, > mark > > > Am 22.12.2015 00:02, schrieb John Pye: >> Hi Mark >> >> (Sorry for the delay. Not sure why you didn't get the email (perhaps >> filtered as spam?). Hope you get this one. I set up an account for you >> on the wiki. You should have received an email.) >> >> Regarding the properties database, I should mention that Richard >> Towers did a bit of work on implementing XML storage for fluid >> properties. We didn't complete the integration work, but there's some >> interesting stuff there, including the ability to render the XML to >> HTML using XSD, for easy human-readable checking/review of correlation >> data that has been entered. Some kind of editable data file is good >> for people wanting to add new species, but at the same time, it adds >> some parsing overhead to the codebase compared to the current approach >> of declaring C99 data structures. >> >> I don't think that reusing the ASCEND matrix routines is the >> necessarily the way to go for property calcs. They are really >> specialised on solving, don't include lots of other features such as >> those you mention. Are the matrices very large? Possibly dense matrix >> routines will be better. >> >> Cheers >> JP >> >> On 18/12/15 21:35, [email protected] wrote: >> >> Hi John, >> I didn't receive your answer back then (did just check my mails...no >> mail from you on that date...very strange). >> >> I need to transpose the matrix >> >> to >> >> a, b and c are the interaction parameters which are stored in the >> modified UNIFAC + PSRK database provided by the UNIFAC Consortium >> (http://unifac.ddbst.de/ [5]). >> >> Later the matrix has to be multiplied with another matrix. There is an >> excel sheet from which one can learn how the calculations are carried >> out: http://www.egr.msu.edu/~lira/computer/EXCEL/ACTCOEFF.XLS [6] >> >> It's quite a hassle to understand PSRK (SRK + Mathias Copeman + modified >> UNIFAC group contribution method) only with literature since >> equations/variables change quite often depending on the paper and the >> equation system isn't always complete. >> >> I would like to document the whole equation system and the calculation >> in the wiki. Could you make me an account for the wiki? A password for >> the svn repo would also be great! >> >> Considering the fixed physical properties database: >> >> The JSON suggestion sounds very interesting. Loïc d'Anterroches and his >> chemeo project (https://www.chemeo.com/ [7]) has just recently >> released an >> API for the property database also based on JSON. Maybe one could try to >> connect Ascend with Chemeo for receiving (online or even just >> downloading the whole database via the API) property data in the future. >> >> Have to dig through the whole ascend/linear folder the next days to >> understand how the C code interacts with ascend. I'll keep you posted >> how I will progess. >> >> So a wiki and svn account would be great! ;) >> >> Cheers, >> mark >> >> ------------------------------ >> >> Message: 4 >> Date: Sun, 8 Nov 2015 11:03:05 +1100 >> From: John Pye <[email protected]> >> Subject: Re: [ASCEND] PSRK Model >> To: <[email protected]> >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="windows-1252"; format=flowed >> >> Hi Mark >> >> That sounds great! Did you implement this as part of FPROPS, or >> something new? >> >> I'm not immediately clear why you need matrix operations here. Perhaps >> you could explain that to me. Actually, ASCEND doesn't contain a full >> set of matrix operation routines -- it isn't needed in there. There is >> the fairly extensive sparse matrix code, 'mtx' >> (ascend/linear/mtx_basic.h for example). There is also a small dense >> matrix data structure (ascend/linear/densemtx.h) with a few minor >> operations provided. But if you want complete set of matrix tools, >> consider blas/linpackYou can link to BLAS/LAPACK (dense) or >> csparse/cxsparse (sparse), if you really need those features. We're >> already linking those in ASCEND in some places, in some cases, so it's >> certainly possible. >> >> Regarding the SQLite database idea, you will see lots of data for fluid >> properties currently coded in C structs, for example >> http://code.ascend4.org/ascend/trunk/models/johnpye/fprops/fluids/ammonia.c?view=markup >> >> [1] >> >> These are the kinds of structures we would need to be able to encode in >> database form. Certainly it's possible, but I think it's going to get >> fairly complex fairly quickly. Another idea I thought of was to use XML >> or some other markup language (YAML? JSON?) as the 'store' for FPROPS >> data, but then to process that down to C code at compile time, so that >> no complicated dependencies in the runtime code are needed. >> >> Another point to raise is that we recently implement TTSE routines for >> FPROPS. This is still alpha, not merged to trunk, but it's an example >> in >> FPROPS where a *lot* of pre-calculation is required, which can >> certainly >> be considered for storage in a file or database. Whether SQLite is the >> best option, I couldn't say. >> >> If you would like to add your code to a branch in our svn repo, please >> me know and I can set up a password for you. >> >> Cheers >> JP >> >> On 08/11/15 03:11, [email protected] wrote: >> Hi there, >> I managed quite a deal for setting up a PSRK model for ascend. >> >> What's missing?: Transposing a matrix and multiplying two matrices. >> Has somebody already written some functions for matrix algebra in C and >> wrapped them? Otherwise I will beginn with that the next days by >> following this HOWTO: >> http://ascend4.org/Writing_ASCEND_external_relations_in_C [2] >> >> When the PSRK model finally works I want to set up a SQLite database >> for >> all the thermodynamic and physical property data by tackling this task: >> http://ascend4.org/Student_Projects#Thermophysical_properties_database [3] >> >> >> Cheers, >> mark >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Ascend-sim-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/ascend-sim-users [4] >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Ascend-sim-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/ascend-sim-users [4] >> >> >> >> Links: >> ------ >> [1] >> http://code.ascend4.org/ascend/trunk/models/johnpye/fprops/fluids/ammonia.c?view=markup >> >> >> [2] http://ascend4.org/Writing_ASCEND_external_relations_in_C >> [3] >> http://ascend4.org/Student_Projects#Thermophysical_properties_database >> [4] https://lists.sourceforge.net/lists/listinfo/ascend-sim-users >> [5] http://unifac.ddbst.de/ >> [6] http://www.egr.msu.edu/~lira/computer/EXCEL/ACTCOEFF.XLS >> [7] https://www.chemeo.com/ ------------------------------------------------------------------------------ _______________________________________________ Ascend-sim-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ascend-sim-users
