ASCEND - User contributions [en]

Student projects

2018-02-02T14:53:05Z

Mike:

Welcome to [[Main Page|ASCEND]]! You might want to read our [[ASCEND overview|overview]] to learn a bit about our project, or read about our more general [[Development Activities]]. This page gives a long list of possible student projects with our project, which means potential [[GSOC2018]] projects, or possibly undergrad or post-grad research projects, such as for engineering final-year students. Our contact details are [[Support|here]].

'''Last updated Jan 2018.'''

= Recommended projects =

We have assigned '''priorities''' to these projects. All things being equal, we will choose students who propose high-priority projects. However, all things are not equal; if we receive a very strong proposal from a student who has done lots of preparatory work, then we will probably choose that student over a lower-quality proposal for a higher-priority project.

== Graphical flowsheet editor ==

Similar to the flowsheet editor in chemical process modelling software such as ASPEN, ASCEND has a [[canvas-based_modeller_for_ASCEND|Canvas-based modeller]] which is currently in development, and not yet quite usable. We would like to push this nice new interface closer to usability. The next step in the implementation, be believe, is to implement proper 'connector' logic, including annotation which which variables should be connected in a 'potential' sense (eg. voltage, temperature), and which which should be connected in a 'flow' sense (eg. current, energy). Connectors should be able to connect a number of related variables at once. Also it would be good to present documents/tutorials to users for solving practical problems. Before going ahead with this project, we would like to discuss implementation details with interested students.

* Contact person: [[John Pye]], [[User:Mike|Tengda (Mike) Han]]
* Level of difficulty: Medium
* Priority: Medium/High
* Languages: Python, possibly a small amount of C/C++
* Also useful: Cairo/PyGTK/PyGI, design patterns for GUI programming

== Parallel optimisation solvers for ASCEND ==

We would like to develop optimisation solvers for ASCEND using particle swarm optimisation (PSO) or a hybrid of PSO with gradient-based Newton solver methods. Such methods are amenable to parallelisation, and should be considerably faster for certain kinds of models with modern hardware. Connecting to an existing open-source solver would be preferred, but only if it makes good sense architecturally. Before starting, we would like to discuss possible implementation approaches. It's important to note that current ASCEND is not thread-safe, so care may be required depending on the approach that is taken.

* Contact: [[John Pye]], [[Ben Allan]]
* Languages: C
* Difficulty: Medium-High
* Priority: High

== FPROPS ==

Our [[FPROPS]] fluid properties library within ASCEND is used to calculate the properties of pure fluids (enthalpy, pressure, temperature, density, viscosity, conductivity, etc) with high accuracy. We would like to extend its capabilites in various ways: (1) add support for mixtures, (2) add support for more equations of state, especially cubic equations of state such as Redlich-Kwong and others, (3) add support for incompressible liquids, (4) add support for humid air calculations, (4) demonstrate its use in flash, heat exchanger and reactor models in ASCEND. This project requires someone with background in engineering thermodynamics (for example, having studied the [http://www.amazon.com/dp/0471661740 Sandler book] or similar), because the theory from that book is a necessary starting point for the project.

* Contact: [[Mahesh Venkataraman]], [[John Pye]], [[Krishnan Chittur]]
* Languages: C and maybe a small amount of Python
* Must know: engineering thermodynamics (eg. the [http://www.amazon.com/dp/0471661740 Sandler book])
* Difficult: Medium
* Priority: High

== Gibbs equilibrium reactor model ==

We would like to implement a robust tool for calculating reaction equilibrium using Gibbs free energy minimisation. This needs to be done in a way that is compatible with the ASCEND approach to declaring [[MODEL]]s etc., and should make use of [[FPROPS]] for the calculation of the properties of each component. We have some sample code in MATLAB; a first step might be to convert that code to C and connect it to FPROPS. We will need to simultaneously discuss how to interface to the code to ASCEND so that it can be used in the context of flexible modelling of chemical process flowsheets.

* Contact person: [[Mahesh Venkataraman]], [[John Pye]]
* Level of difficulty: Medium
* Must know: engineering thermodynamics (eg the [http://www.amazon.com/dp/0471661740 Sandler book])
* Priority: Medium/High
* Languages: C

== CAPE-OPEN thermodynamics ==

[http://www.colan.org/ CAPE-OPEN] is a well-documented API for evaluating thermodynamic properties of mixtures, running flash calculations, etc, which exists in the chemical process simulation community. In this project, we'd like to develop a first proof-of-concept integration of CAPE-OPEN into ASCEND. It is suggested that we might use the CAPE-OPEN thermodynamics library provided by [http://dwsim.inforside.com.br/wiki/index.php?title=CAPE-OPEN the DWSIM project], although other possibilities exist. Importantly, we need this approach to work on Linux as well as Windows, and this may complicate matters. However, on the whole, it should be possible to achieve this integration in a relatively straightforward way using our support for external functions (eg see [[writing ASCEND external relations in C]]). Having CAPE-OPEN support with greatly increase ASCEND's access to range of high-quality thermodynamic property engines, which would be very helpful in improving the usefulness of our code.

* Contact person: [[John Pye]], [[Mahesh Venkataraman]], [[Krishnan Chittur]]
* Level of difficulty: Medium (/ Low?)
* Must know: chemical engineering thermodynamics (eg the [http://www.amazon.com/dp/0471661740 Sandler book])
* Priority: Medium/High
* Languages: C, possibly others for 'gluing' to the CAPE-OPEN DLLs/COM objects

== Dynamic modelling improvements ==

This project would build on the progress with [[dynamic modelling]] by [[User:Ksenija|Ksenija]] in GSOC2012-2013. We would like to improve our new [[EVENT]] syntax and extend its support to a range of problem types not yet supported, such as periodic events, and make further changes to the ASCEND language to make dynamic modelling more 'natural'. We would like to work on the efficiency of the [[ODE]]/[[DAE]] engines, to ensure that integrator restarts after boundaries are as efficient as possible.

* Contact person: [[John Pye]]
* Level of difficulty: High
* Priority: High
* Must know: numerical methods
* Languages: C, plus possibly some use of lex/yacc

== Debugging tools for DAE modelling ==

We would like to implement tools that make it easier to determine degrees-of-freedom problems for initial value problems, and possibly implement index reduction into ASCEND. One possible algorithm is that by Soares and Secchi (see [http://cepac.cheme.cmu.edu/pasi2011/library/secchi/Soares_Secchi_Dycops-2007_p217.pdf Soares_Secchi_Dycops-2007] or (somewhat different) {{doi|10.1016/S1570-7946(07)80063-0}}).

* Contact person [[John Pye]]
* Level of difficulty: High
* Priority: Medium
* Must know: numerical methods, differential equations, graph theory
* Languages: C

== Improvements to the Conditional Modelling syntax ==

ASCEND provides support for [[Conditional modelling]] in the form of language constructs and a solver called [[CMSlv]]. Unfortunately the syntax available for conditional modelling is unintuitive. It could be improved by a student willing to delve into the dark corners of the ASCEND compiler and willing to learn about the Flex and Bison parser/compiler tools. Further work on this project could include a rigorous test-suite to demonstrate that all aspects of the conditional model parser and corresponding solver are working OK. Additional further might include enhancements to the graphical interface to make it more obvious to the user when parts of the model are switched on and off as a result of changes in IF or WHEN statements, or alternatively completion of the conditional modelling support for the dynamic modelling solver [[IDA]]. This is another item that would benefit from a [[New Compiler]] effort.

* Contact person: [[John Pye]], [[Art Westerberg]]
* Level of difficulty: medium
* Priority: High
* Languages: Flex/Bison, C

= Other projects =

The following list contains a range of projects that we consider either harder to tackle, or lower priority, or which require very particular skills.

== Python bindings rewrite ==

We would like to review and improve the way that ASCEND accesses its low-level C functionality from Python. Currently this is done via C++ using the [http://www.swig.org SWIG] interface generator. Our preference is probably to keep using SWIG, but to eliminate the C++ layer. Alternatively, a different type of interfacing tool like Cython could be used instead. The new wrapping/langugage bindings would need to be tested via a set of test suites, and program examples in Python provided. It would not be necessary to translate the GUI code to use this new wrapper, although that would certainly be desirable.

* Contact: [[John Pye]]
* Languages: C, Python, C++, SWIG
* Difficulty: Medium
* Priority: Medium

== MSYS2 ==

We would like to implement a new build process for ASCEND for Windows, based on the use of [https://msys2.github.io/ MSYS2]. MSYS2 is a command-line environment similar to Linux. It offers the usual GCC compilers etc, plus a package manager with pre-compiled versions of many of our dependency libraries and tools. This project would require (1) modifying current SCons build files so that they work correctly with MSYS2 (compared to older MSYS), (2) ensuring that all required dependencies are also available in MSYS2 and (3) producing a new installer for ASCEND, by updating our current NSIS-based scripts, that makes use of the MSYS2 binaries built in 1 and 2.

* Contact person: [[John Pye]]
* Languages: Python, C, NSIS
* Must know: usability principles
* Level of difficulty: Low/Medium
* Priority: High

== GTK3/Python3 ==

We have already done quite a bit of work (eg [[User:Adrian]]) on adapting ASCEND to work with GTK3 (PyGI, PyGTK3). Next we need to update ASCEND so that it works correctly with Python3. This will require some work using SWIG to update our Python wrapper to work with Python3. It will also require some changes to the Python GUI (code in {{srcdir|pygtk}}. Finally, it is very important to check that the build and install processes work correctly with Python3 on both Windows and Linux as a minimum.

* Contact: [[John Pye]]
* Languages: Python, SWIG, possibly some C/C++.
* Difficulty: Low/Medium
* Priority: High

== Automated parameter-setting for dynamic models ==

With the addition of [[SOLVE]], [[SOLVER]] and [[OPTION]] statements to the ASCEND language, we now have a way to specify all the necessary parameters for most of the ASCEND solvers like [[QRSlv]], [[IPOPT]] and others. However, this implementation doesn't work with our [[ODE]]/[[DAE]] solvers like [[LSODE]] and [[IDA]]. This project would involve extending the ASCEND language in a way that dynamic models could be easily initialised and solved using statements in [[METHOD]] syntax. A careful review of the [[OPTION]] syntax is also required, as it appears that in some cases the current approach fails to pass through parameters if the solver has already been connected to the system. There is no tough mathematics involved in this project; mostly it's about data structures and information-passing, but efficient software design will be very important.

* Contact person: [[John Pye]]
* Very helpful: experience on a large software project (or software engineering studies)
* Level of difficulty: Medium/high
* Languages: C, Python

== Automated connector routing for the canvas-based modeller ==

When working on big simulation models, line routing can be annoying and tedious, but with a sufficiently clever constraint-based solver, algorithms can be used to automate the task, leaving only minor tweaking required to complete a diagram. Our collaborator on the [[canvas-based_modeller_for_ASCEND|canvas-based modeller]], [[Arjan Molenaar]], [https://github.com/amolenaar/adaptagrams has been working] to integrate Michael Wybrow's [http://adaptagrams.sourceforge.net/ adaptagrams] library into Gaphas, to add support for automatic line routing. At this stage he has got partial Python bindings for the needed parts of adaptagrams, but not plan yet exists for how that will be incorporated into Gaphas or thence to our canvas-based modeller. This project would require someone with good Python skills to work in Gaphas as well as ASCEND to development this functionality.

* Contact person: [[John Pye]] and Arjan Molenaar would hopefully help out as an informal mentor
* Level of difficulty: Medium
* Priority: Medium
* Languages: C

== Bug Squashing ==

We've got a [http://ascendbugs.cheme.cmu.edu/ big long list] of bugs and feature requests (as well as [http://ascendbugs.cheme.cmu.edu/roadmap_page.php a shortlist]) that a student could certainly work on with success. Many of the bugs can be fairly easily fixed and just need a little time. Someone with the right C/C++/Python programming background plus understanding on numerical methods and hopefully some understanding of compiler design and/or GUI design could really make a difference for us.

* Contact person: [[John Pye]]
* Level of difficulty: variable, depends on the bugs you choose to fix
* Must know: numerical methods
* Languages: primarily C, and then possibly Python, C++, Flex/Bison, SWIG, Tcl/Tk, PyGTK,...
* Priority: Medium/High

== Persistence of modelling results ==

Currently, ASCEND models are loaded and solved afresh each time. But sometimes, it can take a bit of fiddling to achieve solution of a model. In these cases, it would be useful to be able to save the model state and load it again into ASCEND. A coherent proposal for how to do this needs to be prepared, in discussion with the ASCEND team, by a student who would like to work in this area. Because this task involved loading and saving model state, it is proposed that it could also incorporate more general data export functionality, eg to export whole/partial model results to a CSV or tab-delimited file, for use with other tools. How this system would work with 'observers' and 'integrator' output is an open question. See also [[Saving and restoring model state]]. Especially important that the design of this component would work nicely with the new [[canvas-based modeller for ASCEND]].

* Contact person: [[John Pye]]
* Level of difficulty: Low-medium
* Languages: C, Python, possibly some Tcl.
* Priority: Medium

== Packaging for Mac ==

We want to get ASCEND working for Mac! We previously did a lot of the work (see [[Porting to Mac]]), but since then Python3 and GTK3 have become commonplace, and we also need to develop an ASCEND bundle/installer/disk-image that feels nice and Mac-ish, but doesn't cause too much disruption to the overall codebase. One key challenge is to provide suitable Apple Event bindings so that models can be opened using the ASCEND GUI.

* Contact person: [[John Pye]], [[Art Westerberg]]
* Level of difficulty: low-medium
* Priority: Medium
* Languages: Python, C, and a fair bit of general Mac OSX knowhow

== New Compiler ==

If you've got a strong background or interest in designing parsers/lexers/compilers, we'd be interested to discuss possible ways to write a new compiler for the ASCEND language. The original ASCEND compiler uses Flex/Bison, but perhaps we can make something more efficient and easier to maintain using more modern tools, perhaps such as ANTLR. See also [[New Compiler]]

* Contact person: [[Ben Allan]], [[John Pye]]
* Level of difficulty: very high
* Languages: flexible, would need to interface with current instance hierarchy C code
* Priority: Medium

== Model Export Engine Experiments (MEEE!) ==

A number of the other projects on this page are concerned with converting a model into some format appropriate for use with another tool. There are actually two kinds of objects both ambiguously known as ASCEND models:

* an ascend TypeDescription: a list of statements that must be interpreted somehow to derive a data tree (Instance) in memory.
* an Instance data tree (which, in principle, may contain references to unexecuted statements from the TypeDescription or may be 'completed').

Potential approaches:

* Conversion of C TypeDescriptions to equivalent classes in some other language is the most general form of model reuse, but requires careful implementation of the conversion operation. A general solution would be to create, or expose in a convenient form, visitor functionality over a self-consistent list of related TypeDescriptions for type-translation plugins to convert to other languages. In the compiler science world, the ascend TD is most related to an AST.
* Conversion of ascend model source via an independent parser to another language. This approach 'reinvents' the ASCEND AST and grammar, but may then be much more translator friendly-- e.g. Java or other tools could be used for implementation with no direct reference to the existing C code base.
* Define a visitor API for conversion of instance data structures to classes in other languages. These classes may or may not look anything like the original object-oriented models. Note that conversions of this sort to flat-file data storage formats (for reloading in ascend later) and to object-free (flat) modeling languages are in the ascend code base already.

See also: Persistence, Openoffice below.

* Contact person: [[Ben Allan]], [[John Pye]]
* Level of difficulty: medium
* Language: C / ANTLR / others
* Priority: Medium/Low

== Internationalisation ==

ASCEND has some bugs when used in locales that use the comma ',' as the decimal point separator. Furthermore, its user interface is in english only, with the exception of some standard menus that GTK+ provides translations for. This project would work towards internationalising ASCEND, starting with solving the decimal point problem, then translating the Python GUI, then moving on into the C library part of ASCEND. It would not be intended that the modelling language itself would be translated, though, nor would the decimal point separator in model files change from the default "." -- the same model files need to work for everyone.

* Contact person: [[John Pye]]
* Level of difficulty: low
* Languages: Python, C
* Priority: Low

== Structural Mechanics Solver in Graphical flowsheet editor ==

As mentioned above, ASCEND has a [[canvas-based_modeller_for_ASCEND|Canvas-based modeller]] which is currently in development. We would like to explore and develop more functionality for this canvas-based modeller. One possible direction is to build a structural mechanics solver to solve mechanics problems. Ideally users can draw the structure in the modeller, with various loading condition and constrains. The solver should solve the structure according to equilibrium equations and return the required answers. We can start with some simple structure from mechanics textbooks, and extend to complicated situation like buckling and advanced beam theory, etc. Of course, it would be good to present documents/tutorials to users for solving example problems. Ideally, for this project you should have some elementary (undergraduate) mechanics knowledge.

* Contact person: [[User:Mike|Tengda (Mike) Han]], [[John Pye]]
* Level of difficulty: Medium/Low
* Priority: Low
* Languages: Python
* Also useful: Cairo/PyGTK/PyGI, design patterns for GUI programming

== Your Own Ideas ==

There are many other areas of possible work on ASCEND, including those from our long list of current and future [[Development Activities]]. Feel free to discuss other possible ideas with us!

* Contact person: write to the 'users' mailing list (see [[Support]]).

[[Category:Development]]

GSOC2018

2018-02-02T14:28:47Z

Mike: add 'student projects' hyper-link

ASCEND is applying to participate in [https://summerofcode.withgoogle.com/ GSOC] in 2018. Please read below if you are interested in participating!

The following application guidelines are retained for future reference.

== General information ==

GSOC is a programme that lets students be paid for work that they do to contribute to an open-source software project. It is a competitive programme for which students must make themselves known to the software project directly, and then apply to Google for selection. Students who get involved well in advance of the deadlines usually have a much better chance of being selected. Some links for people wanting to learn about GSOC for possible future participation:
* [https://en.wikipedia.org/wiki/Google_Summer_of_Code general information about the programme (wikipedia)]
* [https://developers.google.com/open-source/gsoc/faq GSOC FAQs]
* [https://developers.google.com/open-source/gsoc/timeline timeline]
* '''[[Student projects]]''': our list of project ideas with ASCEND (or propose your own)
* [[:Category:GSOC]]: read about ASCEND projects/students with GSOC in previous years
* '''our application template''' is at the bottom of this page.

We'd like to encourage anyone interested in our project to get in contact with us, and make a proposal! In general, the best way to learn about ASCEND is first to actually try to use it: so, ''please, [[SvnInfo|get the code]], [[Building ASCEND|build it]], try writing some models'', ponder our [[student projects]] list, and make your proposal. If you would like to discuss any of this, you can [[Support|get in contact with us]].

Please note that to actually formally apply to participate in the GSOC, you must do so via the GSOC website, you don't apply to us.

== Ways to get involved ==

* read the [[ASCEND overview]] and understand what ASCEND actually does.
* download our 'trunk' code [[SvnInfo|using subversion]] then [[Building ASCEND|build it]], and then [https://lists.sourceforge.net/lists/listinfo/ascend-sim-users let us know] about any issues you come across. Try to help us fix those issues. If you want an overview of the code, see our [[Developer's Manual]].
* ''use'' ASCEND! write some models to solve some problems that you have come across in your coursework or elsewhere. Preferably they should be non-trival: simultaneous nonlinear equations, optimisation problems, dynamic problems, etc. Send us your completed models, and work to make them general and reusable. Make use of existing reusable models from our [[model library]] where possible. If we see someone who's actually worked out what ASCEND is and how to use it, we're much more likely to sit up and pay attention!
* read our [[:Category:Documentation|documentation]] and help us to improve it: this is a wiki, so anyone can edit it. (Note: because of endless spam, you have to first register and we have to manually review your submission, but if you look like you're a real human-being person thing, then we're happy to have you.)
* take a look at our [http://bugs.ascend4.org|bug tracker] and find a bug that you can fix, or a feature request that you can implement
* get onto our [https://lists.sourceforge.net/lists/listinfo/ascend-sim-users mailing list] and open a discussion on features you would like to see in ASCEND
* talk to your professor about ASCEND, and whether there might be ways to incorporate project work with ASCEND into your degree.
* you might like to try tackling some little example problems that we previously used as tests for our GSOC applicants: [[OpenMP Exercise]], [[ANTLR exercise]]. We'll update here if we manage to write any new example problems.
* take a look at our [[Student projects]] page for some existing GSOC projects. Surely, you are very welcomed to propose your own project!

== Application template ==

'''''The following is the 'application template' that you can use when submitting your formal proposal to ASCEND via the GSOC website. Please check back here before the application deadline to ensure you have included all of the requested information. Please take care with formatting, and try to use a concise style.'''''

'''About you'''
* Name: full name (preferred 'friendly' name in brackets)
* Email:
* Location: country, city during coding period
* University: current university and course, year started, length, expected completion date.
** Please include an email address and website reference for a '''professor at your university''' whom we can contact to confirm your enrolment status if required.
* Skype ID: (if you have one)
* Are you subscribed to our [[Support|ascend-sim-users]] mailing list? YES/NO (we prefer YES!)
* Phone number: (optional)
* URL link to your CV: (optional)
* URL link to your personal blog/homepage: (optional)

'''Project proposal'''
* Project title as provided on the [[Student projects]] page (or something of your own)
* Then, a description of the project ''in your own words''. What do you think you will be able to achieve, and what will your approach be? Why did you choose this idea?
* What progress have you made already? This might be a more detailed plan, getting up and running, some initial coding, familiarising yourself with related tools, or some general bug-fixing or bug-reporting for ASCEND more broadly.

'''Milestones'''
* What are the goals of your project? Are they [https://en.wikipedia.org/wiki/SMART_criteria ''specific'', ''measurable'', ''achievable'', ''realistic'' and ''time-specific'']?
* Give a schedule, showing the order in which you will achieve the specified goals. If possible, show that you have discussed the plan with your proposed mentor.

'''Other commitments'''
* We expect our GSOC students to be online (we prefer Skype) and immediately contactable for at least 35 hours a week, working directly on their GSOC project. If you expect this to be difficult, or if you expect to work at odd hours, we want to know in advance.
* Note that we require an ''absolute minimum'' of a weekly email update from all our students.

'''Programming language experience/expertise'''
* Programming languages you have learnt, and how many lines of code, approximately, you have written in each.

'''Relevant experience'''
* List jobs, projects, courses etc that show that you have the required knowledge and experience for this project. Explain briefly how they relate to the project you are seeking.
* Only list things that are relevant, we don't want your whole CV.

'''Experience with ASCEND'''
* Is this your first contact with the ASCEND project?
* List or link to any code, patches, documentation or bug reports contributed to ASCEND or other projects.
* Please give us as much evidence as you can to show that you have got our code running on your machine -- compiled it from the source code yourself -- and that you've figured out how to use it independently. The more independent use that you can show, the better. If you've identified a bug, report it and link to your bug report. If you've written a new model, or some new code to add, tell us about it. The more you've done, the easier it is for us to trust in your ability to contribute.

'''Why ASCEND?'''
* If you can, say something insightful about the ASCEND project ''specifically'' -- something about our project that interests you more than others available in GSOC.

[[Category:GSOC]]

ASCEND Users and Friends

2018-01-31T11:06:20Z

Mike: /* ASCEND Developers */ typo

If you're using ASCEND to solve problems, please let us know!

==ASCEND Users==

* [http://solar-thermal.anu.edu.au/ Solar Thermal Group at '''Australian National University'''] uses ASCEND for a wide range of simulation problems and actively participates in ASCEND development.
* [http://www.che.iitb.ac.in/online/ Chemical Engineering at '''Indian Institute of Technology Bombay'''] and [http://fossee.in FOSSEE], with leadership from Prof Kannan Moudgalya, are working to introduce ASCEND into their chemical engineering curriculum.
* [http://www.cnim.com/en/cnim-and-solar-energy.aspx '''CNIM'''] (France) used ASCEND to model two-phase flow for their new solar collector
* [http://lncmi.cnrs.fr/ Laboratoire National des Champs Magnétiques Intenses, '''CNRS France''']
* [http://www.uantof.cl/D2P/HydroSimLibrary.htm The D2P Research Group at '''Universidad de Antifagasta'''] use ASCEND for solving hydrometallurgy problems. See [http://www.uantof.cl/D2P/reporte%20tecnico.pdf technical report (in spanish)] or [http://www.uantof.cl/d2p/HydroSim.pdf summary (in english)].
* [http://www.che.uah.edu/courseware/toolbox/ascend/ Chemical Engineering at '''University of Alabama Huntsville'''] problems solved using ASCEND for chemical engineering coursework
* [http://pedro.valelima.com/phd/ Pedro Vale Lima] contributed some documentation on doing [[Thermodynamics with ASCEND]].
* [http://www.bystronic.com/ Bystronic] are working on using ASCEND as a computation engine for embedded controllers.

== ASCEND Developers ==

See also [[ASCEND history]] and [[:Category:ASCEND Contributors]].

{| class="wikitable"
|-
! Name
! Connection
! Mugshot
|-
| Ben Allan
| A principal member of the technical staff, Sandia Laboratories/CA. Research interests include large-scale OO modeling support tools (solution methods & compilers), scalable design of human-computer interaction, and optimizing finite-element data representations.
| [[Image:BenAllan.jpg]]
|-
| [[User:Kchittur|Krishnan Chittur]]
| Professor, Department of Chemical and Materials Engineering, University of Alabama Huntsville, Alabama. Research interests include biomaterials and bioinformatics. An enthusiastic ASCEND user who would like to see it being widely used for computations, simple and complex.
| [[Image:KrishnanChittur.jpg]]
|-
| Luis Cisternas
| Professor, Departamento de Ingeniería Química, Universidad de Antofagasta, Casilla 170, Antofagasta, Chile. Research interests include Chemical and metallurgical process & product design, Process systems modelling and optimization, Process synthesis. Developer of the ASCEND library [[HydroSim]] for hydrometallurgy applications.
| [[Image:LuisCisternas.jpg]]
|-
| [http://engn.anu.edu.au/OurPeople/index.php?StaffID=3627027 John Pye]
| Lecturer at the Dept of Engineering, Australian National University, Canberra, Australia. Research interest: Solar thermal energy systems, thermal system modelling, thermochemical energy storage by ammonia dissociation, structural modelling and optimisation of parabolic reflectors.
|-
| [[Vicente Rico-Ramirez]]
| Professor, Department of Chemical Engineering, Technical Institute of Celaya, Mexico. Research interests in optimization, modeling, synthesis.
| [[Image:VicenteRicoRamirez.jpg]]
|-
| Jon Shao
| Assoc Prof, Institute of Systems Engineering, Zhejiang Univ, Hangzhou, China. Research interests in advanced optimization/solution strategies for complex systems, RTO, automatic differentiation, support environments for solving complex problems, and very long distance supervisory control and data acquisition.
| [[Image:JonShao.jpg]]
|-
| Jerry St Clair
| Our token organic chemist (doesn't every team need one). An ASCEND user for non-engineering applications. His research interests include reaction mechanisms and kinetics, process optimization and control, and doing with computers what could more easily be done without them.
| [[Image:JerryStClair.jpg]]
|-
| Mark Thomas
| Staff in the Survivable Network Technology Group at the Software Engineering Institute of Carnegie Mellon University.
| [[Image:MarkThomas.jpg]]
|-
| [http://www.cheme.cmu.edu/people/faculty/aw0a.htm Art Westerberg]
| Retired as of June, 2004. Formerly professor in the Dept. of Chemical Engineering, Carnegie Mellon University. Research interests: ASCEND development.
| [[Image:ArtWesterberg.jpg]]
|-
| Duncan Coffey
| Student at CMU. Contributed {{src|models/reactor.a4l}} and {{src|models/kinetics.a4l}} in 1998.
|
|}

OcamlParser

2018-01-31T11:03:27Z

Mike: add to contributor category

For [[GSOC2016]], [[User:Hugo|Hugo]] implemented an experimental parser for the ASCEND modeling language that allows a faster rate of experimentation for new syntactic features compared to the existing ASCEND parser.

The new parser was designed to make it easy to parse ASCEND syntax into a syntax tree, perform transformation passes over this syntax tree and then serialize the result back into a textual format, which can be fed into the existing ASCEND compiler. This lets us implement new language features in terms of existing ones and experiment without needing to modify the core ASCEND compiler.

One advantage of having this new parser and syntax-tree tooling is that working with syntax trees is hard to do in the existing parsing architecture because ASCEND's C compiler parses and interprets the code at the same time, and doesn't give us a chance to apply syntax transformers before the code is interpreted. Another advantage of the new parser is that it is written in [https://ocaml.org/ Ocaml], which as a functional programming language is specially suited for operating on tree-like data structures.

== Compiling and Using the New Parser ==

The code for the new experimental parser as well as the infrastructure for writing syntax transformers can currently be found in the {{srcbranchdir|hugo|}} branch of the ASCEND Subversion repository. It has not been merged into the trunk yet.

<nowiki>
svn co http://svn.ascend4.org/branches/hugo ascend-hugo</nowiki>

To run the new parser and to write syntax transformers, you will need to install the Ocaml compiler, and some Ocaml libraries. The recommended way to do this is to use your distro's package manager to install the Ocaml compiler and the [https://opam.ocaml.org/ Opam] package manager and then use Opam to download and install the required Ocaml libraries.

<source lang=sh>
sudo apt-get install ocaml opam

opam init
opam install menhir containers sequence
</source>

Then, go to the "ocaml" folder in the ASCEND source directory and build things with the makefile. Now you can start playing with the new parser.

<source lang=sh>
cd ascend-hugo/ocaml
make
</source>

The makefile, {{srcbranch|hugo|ocaml/makefile}}, shows how to compile the code and the tests filder has some examples of how to run it. For more details see {{srcbranch|hugo|ocaml/README.txt}}.

== Writing Syntax Transformers ==

The goal of this new Ocaml parser is to support syntax experiments that work by mapping ASCEND syntax trees (possibly with some extensions) into a vanilla ASCEND syntax tree that can be fed into the existing C compiler. However, writing these syntax tree transformers by hand can be a very laborious process because you need to write a lot of code just to traverse the syntax tree and get to the interesting leaves that we might want to modify. (Have a look at {{srcbranch|hugo|ocaml/tokenize_tree.ml}} to see how traversing a tree by hand looks like).

One of the ways to avoid boilerplate traversal code is to use the "Visitor Pattern" and write traversals by extending a default traversal that doesn't do anything. To support this pattern, there is an interface for syntax tree iterators in {{srcbranch|hugo|ocaml/ast_iterator.ml}} as well as a default_iterator that doesn't do anything but that can be easily extended into an iterator that does something interesting in relevant nodes and just walks through everything else. There is also a similar system for transformers (functions that convert one AST into another) in {{srcbranch|hugo|ocaml/ast_mapper.ml}}.

A good example of how to use the tree iteration and transformation modules can be found in {{srcbranch|hugo|ocaml/infer_derivatives.ml}}. This syntax transformer receives makes <code>DERIVATIVE OF</code> declarations optional by inferring them from the uses of the <code>der()</code> operator throughout the program.

[[Category:GSOC2016]] [[Category:Experimental]][[Category:ASCEND Contributors]]

User:Vishnu

2018-01-31T11:03:03Z

Mike: add to contributor category

My GSoC 2016 project will be on the topic '''Adding incompressible fluids EOS to FPROPS'''. The project [https://summerofcode.withgoogle.com/projects/#6628262910361600 details] and [https://drive.google.com/file/d/0B_NSyeBxo3MKQk5oeENjYW1yY00/view?usp=sharing proposal] are on the official GSOC website. My mentors will be [[User:Jpye|John Pye]] and [[User:Mahesh|Mahesh Venkataraman]].

My code is at {{srcbranchdir|vishnu|}}.

= Approach =

Here are some examples of current incompressible fluid support in ASCEND:
* {{src|models/johnpye/liquidsodium.a4c}}
* {{src|models/johnpye/moltensalt.a4c}}

The project is divided into two parts:
# Develop a stand alone code for computing popular thermodynamic properties for incompressible pure fluids as well as mixtures.
#* This includes development of new evaluation functions for incompressible fluids based on polynomial, exponential and exponential-polynomial mathematical models with fitting coefficients extracted from various published journal articles. The development of the stand alone code will finally consist of extensive verification and validation with available data in [http://www.coolprop.org/fluid_properties/Incompressibles.html CoolProp]. The deadline to complete this work will be June 27, 2016 (GSoC '16 mid-term).
# Enhance the FRPOPS module with the features of the developed stand alone code
#* This second part (post mid-term) will consist of developing the incompressible fluid data structures from the existing structures in FPROPS. The property evaluation functions developed in the first part will be then linked with FPROPS, hence completely adding the incompressible EOS to FPROPS.

= Weekly updates =

== Before 23 May 2016 (community bonding period and before) ==
Updates:
# Active participation with ascend-sim-users [https://sourceforge.net/p/ascend-sim/mailman/message/34912089/ link]
# Executed several ready made ASCEND models (for nitrogen and oxygen) provided by Dr. John Pye (that invoke FPROPS)
# Understood the implementation of TTSE (done by Dr. Sidharth Somanathan, GSoC '15 student) [http://ascend4.org/User:Sidharth link]
# Reported minor bug related to the test for 'Nitrogen' [http://bazaar.launchpad.net/~jdpipe/ascend/trunk/revision/2814 link]

Work under progress:
# Understand call graph and data flow of ASCEND-FPROPS models

== 30 May 2016 ==
Updates:
# Identified existing incompressible models written for a pure fluid (liquidsodium) and a molten mixture (KNO3:NaNO3)
# Literature review
#* Found repositories (in JSON format from CoolProp) for extracting coefficient matrices (as discussed in the proposal) of incompressible fluid models (above 100 pure and mixture fluids)
#* Different evaluation functions required for different types of fit coefficients are: polynomial type, exponential type and exponential-polynomial type

Work under progress:
# Understand the implementation of incompressible fluid models in CoolProp
# Start with a standalone code for incompressible fluids
#* Extract the coefficient matrix by implementing a JSON-to-C file parser
#* Implement the evaluation functions

== 06 June 2016 ==
Updates:
# Identified relevant 'C' structures required for incompressible fluids
<blockquote>
<source lang="c">
typedef struct {
char* type;
double** coeff;
int numc_r, numc_c; // number of rows and columns in coefficient matrix respectively
} coefficients;

typedef struct {
coefficients T_freeze, conductivity, density, specific_heat, viscosity, saturation_pressure;
char* x_id;
char* description;
double T_base, T_max, T_min, T_minPsat, x_base, x_max, x_min;
} fprops_incompressible;
</source>
</blockquote>
<ol start="2">
<li> JSON-to-C file parser added to the standalone code and subsequently loaded the incompressible fluid data structures </li>
</ol>

Work under progress:
# Adding property evaluation functions to the standalone code
#* for 'density', 'conductivity', 'heat capacity' and 'viscosity'
#* as function of 'temperature' (as discussed in the proposal)

== 13 June 2016 ==
Updates:
# Still working on incompressible standalone code (please review the committed work)
# Added property evaluation functions for density, conductivity, heat capacity and viscosity
# Added functions to compute properties from different types of fit coefficients: polynomial, exponential, exponential-polynomial
# Analyzed preliminary results for "Zitrec S55, Potassium formate/Sodium propionate"
#* Programmed a macro {{srcbranch|vishnu|models/johnpye/fprops/vishnu/scratch/generate.mcr}} and a script file {{srcbranch|vishnu|models/johnpye/fprops/vishnu/scratch/unite}} to create plots (which works with the post-processing tool 'Tecplot')
#* Results in [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/vishnu/scratch/results.pdf?view=log link], Original data in [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/vishnu/scratch/Original.pdf?view=log link]
#* Large/significant deviations/inconsistencies observed

Work under progress:
# Comparing with respective computations of CoolProp to detect the root-cause behind mismatching results

Future discussion:
# What is the purpose of "NRMS" (normalized root-mean-square provided in the 'JSON' files of CoolProp)? Do I have to include that anywhere in the calculations or is it just additional info?
#: NRMS is just a measure of correlation/agreement between results. When the value is low, it means there is good agreement. Note the ambiguity in the definition around [https://en.wikipedia.org/wiki/Root-mean-square_deviation#Normalized_root-mean-square_deviation 'nomalized']

== 20 June 2016 ==
Updates:
# Dived deep into CoolProp evaluation functions and debugged the existing code for 'pure' fluids.
# Ran test cases for
#* Zitrec S55, Potassium Formate/Sodium Propionate (to test polynomial and exp-polynomial functions) and
#* Water (exponential viscosity model)
# Exponential type model for viscosity - bugs:
#* The model was not based on a centered-fit approach.
#* There is no need to subtract the base property (Temperature in our case) before evaluating the model.
#* Also, there is a change in sign for one of the viscosity coefficients entered in the original JSON files.
# Demonstrated exact results to that generated by CoolProp (compare Original_*.pdf to Results_*.pdf in [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/vishnu/scratch/ repository])

Conclusion: Pure fluids incompressible EOS ready to be merged with FPROPS

Work under progress till July 27 (GSoC mid-term):
# Get the EOS for incompressible mixtures working: Demonstrate match for LiBr
# Add integration functions to evaluate 'internal energy','enthalpy' and 'entropy' (as discussed in proposal)

Further Discussions:
# Please note that models for incompressible mixtures are further complicated as we now have 2D coefficient matrices. Are there simplified models?

== 27 June 2016 (GSoC '16 mid-term) ==
Here is the update:
# Developed a working stand alone code for evaluating incompressible EOS (pure fluids and mixtures)
#* Consists of JSON-to-C parser (for current requirements)
#* Evaluates different types of incompressible EOS: polynomial, exponential-polynomial and exponential for pure and mixed fluids
#* Evaluation functions for different major thermodynamic properties: Density, conductivity, specific heat, viscosity, saturation pressure
# Performed test cases for
#* Zitrec S55, Potassium formate/Sodium propionate (to test polynomial and exp-polynomial functions)
#* Water (exponential viscosity model) and
#* LiBr (mixture)
#* Demonstrated exact results to those generated by CoolProp (compare Original_*.pdf to Results_*.pdf in the [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/vishnu/scratch/ repository]) [* = ZS55, Water, LiBr]

{| class="wikitable"
|+ Verification and validation of incompressible EOS models for pure fluid (Water) and mixture (Lithium Bromide)
|-
! Original from CoolProp
! Test results
! Test results
! Test results
|-
| [[Image:Original_Water.png|thumb|350px|'Density' (polynomial fit), 'Heat Capacity' (polynomial fit), 'Thermal Conductivity' (polynomial fit), 'Dynamic Viscosity' (exponential fit) and 'Saturation Pressure' (exponential fit) profiles of '''''Water''''' (pure fluid)]]
| [[Image:Results_Water-d.png|thumb|350px|Polynomial fit of 'Density' profile for '''''Water''''' (pure fluid) mixture generated by the standalone code]]
| [[Image:Results_Water-tc.png|thumb|350px|Polynomial fit of 'Thermal Conductivity' profile for '''''Water''''' (pure fluid) mixture generated by the standalone code]]
| [[Image:Results_Water-v.png|thumb|350px|Exponential fit of 'Dynamic Viscosity' profile for '''''Water''''' (pure fluid) mixture generated by the standalone code]]
|-
| [[Image:original_LiBr.png|thumb|350px|'Density' (polynomial fit), 'Heat Capacity' (polynomial fit) and 'Saturation Pressure' (exponential-polynomial fit) profiles of '''''LiBr''''' mixture at '''''x = 0.39''''']]
| [[Image:results_LiBr-d.png|thumb|350px|Polynomial fit of 'Density' profile for '''''LiBr''''' mixture generated by the standalone code at '''''x = 0.39''''']]
| [[Image:results_LiBr-hc.png|thumb|350px|Polynomial fit of 'Heat Capacity' profile for '''''LiBr''''' mixture generated by the standalone code at '''''x = 0.39''''']]
| [[Image:results_LiBr-sp.png|thumb|350px|Exponential-polynomial fit of 'Saturation Pressure' profile for '''''LiBr''''' mixture generated by the standalone code at '''''x = 0.39''''']]
|}

Conclusion: Pure and mixed fluids incompressible EOS ready to be linked with FPROPS

Work under progress:
# Add integration functions to evaluate internal energy/enthalpy/entropy
# Start final integration of the current code with FPROPS

Further Discussions:
# Do you know of any published data/equations/results to compare the integrated properties (internal energy/enthalpy/entropy)?

== 03 July 2016 ==
Updates:
# Integration functions added: [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/vishnu/scratch/main.c?revision=3168&view=markup link]
#* It is assumed that specific heats are polynomial functions of input temperature
#* Integration functions for internal energy and entropy calculations for incompressible pure fluid and mixtures are then added according to the equations given in the proposal
#* All incompressible fluids have an arbitrary reference state for internal energy and entropy: During initialization, the reference state is defined as a temperature of 20 C and a pressure of 1 atm according to the U.S. National Institute of Standards and Technology.
Further discussions:
# We don't know if we need a centered fit for this computation too (as in the evaluation functions before)
#* No data available for validation purposes
# How do we deal with enthalpy computation?
#* This depends on input temperature as well as pressure
Work under progress:
# Adding incompressible fluid data structures to filedata.h and rundata.h

== 10 July 2016 ==
Updates:
# Modified the files [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/filedata.h?revision=3149&view=markup filedata.h] and [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/rundata.h?revision=3168&view=markup rundata.h] to store incompressibile fluid coefficients
#* Note that viscosity and thermal conductivity coefficients for incompressible fluids are bound with the incompressible fluid data structure (although there is an option to separate them out)
#* New pointers to departure functions added into PureFluid_struct to facilitate computations of some incompressible fluid properties (freezing temperature, viscosity, saturation pressure etc.)
Work under progress:
# Adding files incompressible.h and incompressible.c
#* Most of the evaluation function will have to be simply copied from the working/validated standalone code

== 17 July 2016 ==
Updates:
# rundata.h and filedata.h in good shape
#* compatible with both pure and mixture incompresible fluids
# Evaluation function declaration and definition completed in [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/incompressible.h?revision=3168&view=markup incompressible.h] and [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/incompressible.c?revision=3168&view=markup incompressible.c] file respectively (except enthalpy, internal energy and entropy)

Work under progress:
# Write the incompressible_prepare() subroutine to load the stored model data from filedata to rundata
# Completing evaluation function for integrated properties (enthalpy, internal energy and entropy)
# Learn final linking of incompressible model through fprops(.h/.c) files

Further discussions:
# Which are the files that need major changes while performing the final binding work (of the incompressible model to FPROPS)?

== 24 July 2016 ==
Updates:
# Finished coding up the evaluation function for integrated properties (internal energy and entropy)
# Completed the incompressible_prepare() subroutine: [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/incompressible.c?revision=3168&view=markup link]

Under progress:
# Binding the incompressible model with FPROPS
# Setting up test cases similar to what was done with the standalone code
#* Focus on Zitrec S55, Potassium Formate/Sodium Propionate (pure) and LiBr (mixture) verification

== 31 July 2016 ==
Updates:
# Initial binding of the incompressible model to FPROPS successful
# Incompressible module tested for Zitrec S55, Potassium Formate/Sodium Propionate (pure) and LiBr (mixture) solution
#* Results consistent with previous test performed with the standalone code
#* Please find the relevant input, source code, post-processing .py scripts and output+plots here: (moved to) [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/test/incomp_misc/ link1] and [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/vishnu/ link2]

Further discussion:
# Here, the underlying fluid state structure in 'fprops' file had to be changed to incorporate the values for concentration (x) and pressure (p)
#* This might affect the assumption made by other EOS models in FPROPS

Work under progress:
# Concentrate binding the pure incompressible fluid part
#* This can be done without changing the fluid state structure
#* But then, it should be noted that it will be 'pressure' that will be actually stored in the variable named 'density' during incompressible EOS computations
#* The mixture part that was coded up will be placed in a backup folder and will be worked upon in the future (post-GSoC '16)

== 07 August 2016 ==
Updates:
# [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/fprops.h?revision=3168&view=markup fprops.h] and [http://code.ascend4.org/ascend/branches/vishnu/models/johnpye/fprops/fprops.c?revision=3168&view=markup fprops.c] files edited to support pure incompressible EOS
# Final binding of 'pure' incompressible EOS model completed

Work under progress:
# Verification of incompressible EOS model with available [http://code.ascend4.org/ascend/trunk/models/johnpye/moltensalt.a4c?view=markup ascend-model] for 'molten salt'
#* More data points from [http://prod.sandia.gov/techlib/access-control.cgi/2001/012100.pdf Sandia-National-Laboratories-report]

== 14 August 2016 ==
Updates:
# Managed to partially get the test case for molten-salt working
#* Approach was to create a 'json' file for the coefficients as given in http://prod.sandia.gov/techlib/access-control.cgi/2001/012100.pdf
#* Debugging and tedious unit conversions (from British to SI and back)
#* Deviations from the SNL paper data are significant for density and specific heat
#* Here are the values (original data, fitted data from code) all in SI units at (T,p) = (1050 F, 1 bar):
#** density (1728,1730)
#** specific heat (1544,1540)
#** viscosity (1.14e-3,1.14e-3)
#** conductivity (0.55,0.55)

Further work:
# Finish molten-salt test case with appropriate error analysis

Discussion:
# No validation data to compare against for integrated properties.
# How to deal with enthalpy calculation? (pressure comes into picture)
# Discussion about functions on computing the reference values: Is it really necessary to add reference states in the evaluation functions if there are many options (and since we don't know which one to use for incompressible fluids)? I assume that the CFD solvers are more concerned with the gradients rather than the absolute values. Or is it important when it comes to computational chemistry?

== 21 August 2016 (GSoC '16 Final Product) ==
Updates:
# Incompressible EOS for pure fluids added and linked to FPROPS
# The test case presented will be that for 'molten salt'
#* 60% NaNO3 and 40% KNO3
#* 12 test points and correlation coefficients from http://prod.sandia.gov/techlib/access-control.cgi/2001/012100.pdf

How to run the test in your Linux machine (assuming svn, scons and other relevant apps are already installed):
* Check out the code from my repository using svn client:
<source lang="c"> svn co http://svn.ascend4.org/branches/vishnu ascend </source>
* Run scons script from fprops folder:
<source lang="c"> cd ascend/models/johnpye/fprops </source>
<source lang="c"> scons </source>
* Run the moltensalt_btu_test executable in the test folder:
<source lang="c"> cd test // or cd ascend/models/johnpye/fprops/test </source>
<source lang="c"> ./moltensalt_btu_test </source>

Output:
<source lang="c">
incompressible.c:107(incompressible_prepare): Incompressible

Test point: 0 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 5.000000e+02 1.200950e+02 3.564000e-01 1.050580e+01 2.845572e-01
Error at T = 5.000000e+02 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

Test point: 1 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 5.500000e+02 1.189845e+02 3.575400e-01 8.607339e+00 2.876921e-01
Error at T = 5.500000e+02 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

Test point: 2 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 6.000000e+02 1.178740e+02 3.586800e-01 7.085347e+00 2.908270e-01
Error at T = 6.000000e+02 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

Test point: 3 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 6.500000e+02 1.167635e+02 3.598200e-01 5.893968e+00 2.939620e-01
Error at T = 6.500000e+02 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

Test point: 4 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 7.000000e+02 1.156530e+02 3.609600e-01 4.987346e+00 2.970969e-01
Error at T = 7.000000e+02 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

Test point: 5 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 7.500000e+02 1.145425e+02 3.621000e-01 4.319625e+00 3.002318e-01
Error at T = 7.500000e+02 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

Test point: 6 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 8.000000e+02 1.134320e+02 3.632400e-01 3.844950e+00 3.033667e-01
Error at T = 8.000000e+02 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

Test point: 7 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 8.500000e+02 1.123215e+02 3.643800e-01 3.517466e+00 3.065016e-01
Error at T = 8.500000e+02 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

Test point: 8 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 9.000000e+02 1.112110e+02 3.655200e-01 3.291317e+00 3.096366e-01
Error at T = 9.000000e+02 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

Test point: 9 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 9.500000e+02 1.101005e+02 3.666600e-01 3.120647e+00 3.127715e-01
Error at T = 9.500000e+02 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

Test point: 10 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 1.000000e+03 1.089900e+02 3.678000e-01 2.959600e+00 3.159064e-01
Error at T = 1.000000e+03 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

Test point: 11 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 1.050000e+03 1.078795e+02 3.689400e-01 2.762321e+00 3.190413e-01
Error at T = 1.050000e+03 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

Test point: 12 {Temperature Density Specific Heat Viscosity Conductivity}
FPROPS at T = 1.100000e+03 1.067690e+02 3.700800e-01 2.482955e+00 3.221762e-01
Error at T = 1.100000e+03 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
</source>

= Edit log =
http://code.ascend4.org/ascend/branches/vishnu/?sortby=log&view=log

[[Category:GSOC2016]]
[[Category:ASCEND Contributors]]

User:Hugo

2018-01-31T11:02:23Z

Mike: add to contributor category

I'm Hugo Gualandi, and am currently pursuing a PhD at [http://www.lua.inf.puc-rio.br/ PUC-Rio university], focusing on programming languages. For [[GSOC2016]] I implemented [[OcamlParser|experimental ASCEND parsers and syntax transformers]].

== GSOC 2016 Project: Improvements to the Conditional Modeling Syntax ==

The goal of my 2016 Summer Of Code project was to improve ASCEND's conditional modelling syntax. The first thing I did was to study the current state of ASCEND's conditional modeling and identify some ways in which the current modeling syntax and semantics could be improved. My findings are documented in the [[#Proposed syntax changes]] section.

My most significant contribution during this project was to implement an experimental alternative parser for the ASCEND modeling language that allows a faster rate of experimentation for new syntactic features compared to the existing ASCEND parser. I documented what this parser does and how to use it in its own wiki page: [[OcamlParser]].

What is left to is leverage the new parser to experiment with the new designs for the conditional syntax and then, after verifying that they work well, implement the required changes in ASCEND's main compiler.

== Proposed syntax changes ==

The main goal of this project was to improve the usability of dynamic and conditional modeling in ASCEND. This includes:

1) Reducing redundancy in the specification
* Right now some models break badly without redundant information ([[FIX]] and [[FREE]] in hybrid models)
* Sometimes, we have redundant information that could have been inferred by a smarter compiler

2) Make modeling less error prone
* Right now, hybrid modeling relies on calling methods that run [[FIX]], [[FREE]] and set variables by hand. This is very error prone and violates some of the ASCEND abstractions.
* I believe that the key to improving this is a better way to specify initial conditions in models.

So far, I have identified many easy places to improve the language regarding point #1. Point #2 is something that ended up being harder than expected. Many of my proposed changes were inspired by the [https://www.modelica.org/ Modelica] system and I would highly recommend checking that out for comparison.

=== Easy redundancy reduction ===

1) We could infer the PREVIOUS and DERIVATIVE OF declarations.

Modelica does this for its language. Its would be just a matter of parsing the model and checking which variables we are using the der() and pre() operators on. Right now, the only thing these declarations do is clutter the model and complain when we forget to specify a declaration.

2) We could allow conditional expressions inside equations.

For example, right now we use [[USE]] statements to turn equations on and off:

<nowiki>
on: P = 3000;
off: P = 0;

ev1: EVENT (too_high)
CASE TRUE: USE off;
END EVENT;</nowiki>

I would prefer to use boolean expressions instead, similar to how it is possible in Modelica. In ASCEND it would look something like this:

<nowiki>
P = if on then 3000 else 0;</nowiki>

Another good application of conditional expressions would be piecewise functions such as min(), max() and abs(). They resulting code can end up more concise than conditional equations.

<nowiki>
x = max(y, 0)</nowiki>

For optimization and [http://book.xogeny.com/behavior/discrete/decay/ advanced tweaking], Modelica also has the `noEvent` and `smooth` operators to "turn off" the automatic event-handling and boundary checking of conditional expressions.

=== Miscelaneous Modelica features ===

Some Modelica features caught my eye. They wouldn't be a big priority for us, but I think its worth mentioning that they exist.

1) You can use a buit-in function to create an event that runs every X seconds. In Ascend I think you would need to abuse a periodic function such as sin() to achieve this effect.

2) The terminate() builtin lets you cleanly halt the integration from inside an event handler.

=== Hybrid modeling ===

For motivation, lets look at the code for a bouncing ball in Modelica:

<nowiki>
model BouncingBall "The 'classic' bouncing ball model"
type Height=Real(unit="m");
type Velocity=Real(unit="m/s");
parameter Real e=0.8 "Coefficient of restitution";
parameter Height h0=1.0 "Initial height";
Height h;
Velocity v;
initial equation
h = h0;
equation
der(h) = v
der(v) = -9.81;
when h<0 then
reinit(v, -e*pre(v));
end when;
end BouncingBall;</nowiki>

Some interesting things that I think of this:
* The Hybrid modeling happens via a `reinit` statement that "sets" a variable to a new value. We were asking if maybe something more general would be needed but Modelica suggests that these "assignments" are enough.
* However, `reinit` is not a plain assignment. It also recomputes the initial conditions appropriately.
* There are special equations for specifying the initial conditions. In more advanced cases, these equations can be things like `der(x) = 0`.

Now, lets compare this to how ASCEND handles [[EVENT]] statements

# Detect when a boolean variable flips from FALSE to TRUE
# Deactivate equations from OTHERWISE clause.
# Activate equations in the CASE TRUE clause.
# Run the evtname METHOD to fix/free variables.
# Run QRSlv
# Run the evtname_end METHOD to undo the changes from step 4

Step 1 can get a bit cleaner if we allow boolean expressions instead of just boolean variables. I think steps 2 and 3 should be covered by regular conditional equations (what the current WHEN syntax does) and does not have to be the responsibility of the EVENT statement.

The really tricky part are steps 4, 5 and 6. This problem of solving the system to find new initial conditions is something that we don't have a good way to express yet in ASCEND. For example, notice how some of the models in the ksenija folder have `before_integ` or `prepare_integ` that should be manually run to find initial conditions. I also needed to do something similar to find steady-state initial conditions in the Lotka-Volterra model I wrote.

Right now, I don't know how to fix this problem of specifying initial conditions but I highly suspect that if we can figure this out, the syntax for the hybrid modeling will follow very naturally.

[[Category:GSOC2016]]
[[Category:ASCEND Contributors]]

User:Georgy

2018-01-31T11:01:30Z

Mike: add to contributor category

'''Georgy Berdyshev'''

The goal of this project is to implement MSYS2 based build process for ASCEND and improve packaging for Mac.

The main task is to improve the ASCEND build processes by creating a new MSYS2 based implementation by modifying and updating the current SCons build files.

The introduction of MSYS2 for the build processes will bring many benefits to ASCEND, such as the possibility to build more easily 64 bit binaries on Windows and to be able to rely on a current gcc compiler suite from MinGWw64.

In contrast, the current build process has to rely on TDMGCC (instead of MinGW used with MSYS) to be able to compile 32bit and 64bit binaries.
MSYS2 would bring many features to the project, such as the possibility to install dependencies in an easy manner and speed up the build process. But most importantly it has much better native Windows API support. Therefore providing a very feature rich and free base for the new build system of ASCEND.

Project details: https://summerofcode.withgoogle.com/dashboard/project/5090588751822848/details/

== Using subversion ==
1) Subversion username and branch: {{srcbranchdir|georgy|}}

2) Changes:

http://code.ascend4.org/ascend/branches/georgy/?sortby=log&view=log

The changes for this project are committed to github and synced regularly with the {{srcbranchdir|georgy|}} subversion branch.

== Using git (github.com) ==

1) Master branch contains merge code from the below branches, that is synced to the subversion branch.

[https://github.com/georgyberdyshev/ascend/tree/master master]
[https://github.com/georgyberdyshev/ascend/commits/master changes]

2) MSYS2 branch contains msys2, swig and changes for mingw64 and native Python support.

[https://github.com/georgyberdyshev/ascend/tree/msys2/python msys2/python]
[https://github.com/georgyberdyshev/ascend/commits/msys2/python changes]

3) NSIS3 branch contains support for a NSIS3 Windows based installer and further improvements.

[https://github.com/georgyberdyshev/ascend/tree/nsis3 nsis3]
[https://github.com/georgyberdyshev/ascend/commits/nsis3 changes]

4) Sundials_2.6 branch contains support for using the newer sundials 2.6 version with ascend.

[https://github.com/georgyberdyshev/ascend/tree/sundials_2.6 sundials_2.6]
[https://github.com/georgyberdyshev/ascend/commits/sundials_2.6 changes]

==Obtaining the source code==
1) Using subversion

svn co http://code.ascend4.org/ascend/branches/georgy

2) Using git

git clone https://github.com/georgyberdyshev/ascend.git

== Using MSYS2 ==

MSYS2 is a new generation of MSYS that works with the <tt>[https://wiki.archlinux.org/index.php/pacman pacman]</tt> package manager.

After obtaining the source code, you can install the required pacman package by running the following commands:

<source lang="sh">
pacman -Syu
pacman -S vim
pacman -S mingw-w64-x86_64-gtk2 mingw-w64-x86_64-gcc \
mingw-w64-x86_64-gcc-fortran mingw-w64-x86_64-python2-numpy \
mingw-w64-x86_64-python2-pygtk subversion swig \
flex bison python2 scons pkgconfig \
mingw-w64-i686-python2
svn co svn://ascend4.org/code/trunk ascend
cd ascend
scons
</source>

It is important to note, that the current version of scons that is being used for the build relies on the msys Python package, that is broken.
Therefore it is required to bootstrap an alternative Python, even though scons runs via msys.
You may either provide a mingw64 install Python or the native win32 Python installation, by specifying the PYTHON variable to scons.

<source lang="sh">
scons PYTHON=/c/Python27/python.exe

or

scons PYTHON=/mingw64/bin/python
</source>

== Project log ==
*[https://github.com/georgyberdyshev/ascend/commit/6962ef6c2ca36ff6cfff85e98c2daeac82619b82 Added SWIG 3 support. Fixes Unknown SWIG preprocessor directive error.]
*[https://github.com/georgyberdyshev/ascend/commit/a9e79e6bb410ea60eb1e3e6b7ad19923216c77bc Fix name of sundials-config command.]
*[https://github.com/georgyberdyshev/ascend/commit/6a0af5af9ada74fca34c24e2ded1859738484994 Detect SUNDIALS 2.6 on MinGW.]
*[https://github.com/georgyberdyshev/ascend/commit/6aa1673da8f26716b5a9080660e24331c38a5759 Detect SUNDIALS 2.6 on MinGW.]
*[https://github.com/georgyberdyshev/ascend/commit/026bd7814daaa17cc7484f012b945ed17449df16 Updated code to use NSISdl plugin.]
*[https://github.com/georgyberdyshev/ascend/commit/8e47a0eb9543933e7d08cd1655c08964b246b792 Added Unicode multi language installer and uninstaller with several languages.]
*[https://github.com/georgyberdyshev/ascend/commit/12eadeb43b8f481f4effe7b6e2ae0baf3556f36e Create NSIS Modern UI 2.0 based installers.]
*[https://github.com/georgyberdyshev/ascend/commit/58c01c61ea9efbb2668bd8e792ab8a299e6e8f14 Display ASCEND website as branding text.]
*[https://github.com/georgyberdyshev/ascend/commit/85ceb7985755a333c0b31c80ad5aaf9053841427 Added initial code to specify and detect the Python executable.]
*[https://github.com/georgyberdyshev/ascend/commit/a8289e3bbf16e27565fe618b0f7d36e7823204e0 Merge remote-tracking branch 'origin/nsis3' into msys2/python]
*[https://github.com/georgyberdyshev/ascend/commit/a0c72c8920e773516f0eea0ee1ddb3c97f35e3e4 Use /usr/bin/env to detect Python.]
*[https://github.com/georgyberdyshev/ascend/commit/c0614cb0273b79beb055fd7f822631c27738dd45 Use /usr/bin/env to detect Python.]
*[https://github.com/georgyberdyshev/ascend/commit/22ccdad3a5b3eca8ec51cb14fd7830f5181f8f28 Detect native win32 Python.]
*[https://github.com/georgyberdyshev/ascend/commit/74d3505f27f68cb566bdc1c732c44f3a75267bf6 Use os.path on Windows.]
*[https://github.com/georgyberdyshev/ascend/commit/2b724c6855d3e1963b5c109dff642abccea8585d Added functionality to detect Windows Python environment.]
*[https://github.com/georgyberdyshev/ascend/commit/17e9afa0b69f34f395c44b7a782858fa59eefeca Request Python environment when using msys2.]
*[https://github.com/georgyberdyshev/ascend/commit/4835282f161f3b53a6d4ab757aa6f366e255d11d Added functionality to detect Windows Python environment independently.]
*[https://github.com/georgyberdyshev/ascend/commit/4e7dd34bad7f1e00175aa916c39049d85531273a Detect bootstrapped Python environment.]
*[https://github.com/georgyberdyshev/ascend/commit/b8ec72f999f7af3f317dcfd1fb424cf29a82720b Added support to bootstrap mingw64 Python from msys2.]
*[https://github.com/georgyberdyshev/ascend/commit/4adaac1c3edcf54ab93634d1b7df6ffec37e9df0 Added functionality to detect additional lib paths for native Python on win32 and win64.]
*[https://github.com/georgyberdyshev/ascend/commit/3b9ed5ca884b0a54e43810821ace02a1cde75191 Show scons generated output files.]
*[https://github.com/georgyberdyshev/ascend/commit/1989b3ba3baa607ab32c111732a95aed1b5eda3f Fix SWIG compilation and Python lib paths.]
*[https://github.com/georgyberdyshev/ascend/commit/38642239f4b0cd846448a55e8356de67c321ab43 Fix compilation and Python lib paths.]
*[https://github.com/georgyberdyshev/ascend/commit/9e2bcb56560e34038036fb249a84d0881b425262 Updated NSIS detection.]
*[https://github.com/georgyberdyshev/ascend/commit/c2f265108f122fb44b82ec6f30ebeceb49157ca6 Updated Tcl detection.]
*[https://github.com/georgyberdyshev/ascend/commit/f1778f9a1891ea601fa17905fc3d4b9ae5fa67cb Merge branch 'sundials_2.6' into msys2/python]

[[Category:GSOC2016]]
[[Category:ASCEND Contributors]]

User:Mike

2018-01-31T11:00:54Z

Mike: add to contributor category

[[Category:GSOC2016]]

Name: Tengda Han ([https://en.wikipedia.org/wiki/Chinese_characters 韩腾达]) (Mike)

University: [http://www.anu.edu.au/ ANU]

Email: tengda.han@anu.edu.au

Summary: I did [[GSOC2016]] for ASCEND. I optimized GUI of Canvas, fixed bugs, developed canvas models and improved canvas language.

* Browse my code here: {{srcbranchdir|mike|}}
* Check out my code using <tt>svn co http://svn.ascend4.org/branches/mike</tt>

== Discussion notes of 12 May 2016 ==

To get the canvas GUI running in the trunk code, I used:

python ~/ascend/trunk/pygtk/canvas/canvas.py

== May 12 to May 22 ==

* Set development environment and play with canvas.

* Find a problem about module 'ascpy' in my branch, which cannot be found in canvas.py.

* But when I run canvas.py of main trunk, module 'ascpy' can be found, but another error is called:'''libascend.so.1: cannot open shared object file: No such file or directory'''

== Discussion notes of 23 May 2016 ==

* cannot find module 'ascpy' is because I need to compile by

scons -j4

* set paths properly before run canvas.py:

export LD_LIBRARY_PATH=~/Desktop/ascend_mike/mike/:$LD_LIBRARY_PATH
export PYTHONPATH=~/Desktop/ascend_mike/mike/models/johnpye/fprops/python:$PYTHONPATH

* find a bug of Adrian's branch, which is, when run the solver, ascend kills the background terminal. Trying different ubuntu system may work.

== May 23 to May 29 ==

* Tested Adrian's branch on ubuntu 16.04 LTS. Previous bug doesn't exist (ascend kills the terminal)

* Try to understand Gaphas and libavoid.

* Link 'libavoid' on ASCEND wiki has 404 error.

* When 'scons' ASCEND in Ubuntu16.04, SWIG error comes. [https://github.com/georgyberdyshev/ascend/commit/6962ef6c2ca36ff6cfff85e98c2daeac82619b82/ sulution here]

== Discussion notes of 30 May 2016 ==

* When try to run canvas.py, should set PYTHONPATH to

ascend_trunk/trunk/model/johnpye/fprops/python

* For Adrian's version
::canvas.py doesn't work because of
Error: sys.path must be a list of directory names
::Reason: installed python-gaphas uses gtk2. But we require gtk3 branch of gaphas, Solution:
cd ~/desired directory
git clone https://github.com/amolenaar/gaphas
git checkout gtk3
git pull
sudo python setup.py install
::However, after canvas.py pops up, ''TypeError: Couldn't find conversion for foreign struct 'cairo.Context''' occurs when click on blank canvas

== May 30 to June 5 ==

* Solved ''TypeError: Couldn't find conversion for foreign struct 'cairo.Context' '' by

sudo apt-get python-gi-cairo

[http://packages.ubuntu.com/trusty/python-gi-cairo This package] is a Python Cairo bindings for the GObject library

* If problems occur when installing gaphas by

sudo apt-get install python-gaphas

[http://www.installion.co.uk/ubuntu/precise/universe/p/python-gaphas/install/index.html/ Check the universe repository] before installation may help

* Undo button works (finishing the work of Adrian), redo haven't been implemented yet.

== Discussion notes of June 6 2016 ==

* Buttons now have labels. By adding ''tb.set_style(Gtk.ToolbarStyle.BOTH)'' after ''tb = Gtk.Toolbar()''

* Delete unnecessary .svg image files in {{srcbranchdir|mike|pygtk/canvas}} only leave defaultblock.svg

* Block icons should be generated by strings, instead of load image. Example: {{srcbranch|mike|models/test/canvas/brayton_fprops_rachel.a4c}}

* Currently svn version is updated to {{changeset|3110}}

* I can improve blocks, firstly to make sure they can be properly solved in canvas.

== June 6 to June 13 ==

* models in {{srcbranch|mike|models/test/canvas/basic_electronics_model.a4c}} have been updated.

* Problems found: every time after using the model in canvas, a '.svg' file of that model will be generated.

== June 13 to June 28 ==

* Working on redo function. Implement redo function in {{srcbranch|mike|pygtk/canvas/undo.py}}

* Fix a bug that rankine_canvas.a4c in {{srcbranch|mike|models/test/canvas/}} cannot run in canvas

* Fix a bug that rankine_stream.a4c in {{srcbranch|mike|models/test/canvas/}} cannot run in canvas

* Fix a bug that rankine_stream_v2.a4c in {{srcbranch|mike|models/test/canvas/}} cannot run in canvas

* Fix a bug that ammonia_synthesis_v2.a4c in {{srcbranch|mike|models/test/canvas/}} cannot run in canvas

* GUI update: Load Library (Ctrl+L) is enabled from menu bar

* GUI update: Correct labels in Block Properties Dialog

== June 29 to July 10 ==

* Fix a bug when adjusting Error/Status Reporter Console

* Rotate(Ctrl+R) and Flip(Ctrl+F) operation is added to menu bar, and keyboard shortcuts of them are enabled.

* Correct current value (I) in running results from {{srcbranch|mike|models/test/canvas/basic_electronics_model.a4c}} library.

* Find a bug: In basic_electronics_model.a4c, when connect 2 ports of T-piece/Branch together and run, Canvas will quit.

* An Error occurs when load canvas files because blocks with same name exist. Solution: 1. add a checker before 'run' or 'save'. 2. avoid reduplicate names when generating blocks.

* Also, a warning 'CompareStatements called with unknown statement' always appears when load files, but seems don't affect the result.

* Add reporter for loading libraries and files.

* Errors including line number can be shown on canvas when loading is unsuccessful.

* Update information in 'Help' Menu

== Discussion notes of July 11 2016 ==

* Automatically generating .svg files when load libraries: save these images into ~/.ascend/tmp

* Preference of units should be improved: modify pygtk/preference.py

* Warning should be displayed when ports not connected

* Models with degree of freedom should not be solved. Warning should be displayed

* In 'Block Properties', equations of blocks should be displayed

== July 11 to July 20 ==

* Correct syntax error in some files

* Improving Block Properties to display equations, by editing relating python files and glade files.

* Warning Dialog added when load new libraries with canvas items existing.

* Warning Dialog added when exiting without saving canvas (still need improve).

== Discussion notes for July 20 2016 ==

* For equation display, some paths may be valuable to check: asclibrary - get module types - library.h - type.h - ismodel(); ascend/compiler - type.descio.h - writedefinition.

* Next Step: Create a library for piping system. Read Mechanics of Fluids. Be careful with flow network & over constrain issues.

== July 21 to Aug 2 ==

* Solve an issue that .svg image files will be generated in pygtk/canvas after load library: create directory 'pygtk/canvas/.temp' and save all the .svg files into that .temp directory. By modifying {{srcbranch|mike|models/test/canvas/blocktype.py}}

* Piping system library can be loaded now. But still working on equations.

== Discussion notes for August 3 2016 ==

* generate .svg files to ~/.cache/ascend, fix the permission issue by function os.path.expanduser(path).

* Combine Quit (Ctrl+Q) and close button together by assign 'dispensable' argument i.e. Event=None.

* Refresh the workflow for developing piping system model.

== Aug 3 to Aug 9 ==

* 'inout' port is partially implemented by adding similar 'inout' elements with previous 'input' and 'output' elements properly. However error occurs when right click and view 'block properties'.

* Piping system library can solve simple piping problems under fluid mechanics approximation.

== Discussion notes for August 10 ==

* Report current working status.

* General discussion about piping system library.

== Aug 11 to Aug 18 ==

* 'inout' port is fully implemented by checking glade file {{srcbranchdir|mike|pygtk/glade/bp.glade}} and match the variable names. Now, 'inout' port works properly for drawing feedback (can be connected with input/output/inout) and solving.

== Discussion notes for August 19 ==

* Report current working status.

* Schedule next meeting on Monday morning.

== Aug 19 to Aug 22 ==

* Potential connector and flow connector can be detected from library file via syntax 'potential:' and 'flow:', however it only has effects for one layer. E.g. library like this doesn't work:
MODEL electron_stream;
V "potential:" IS_A voltage;
I "flow:" IS_A current;
END electron_stream;

MODEL equipment;
inlet "in:" IS_A electron_stream;
outlet "out:" IS_A electron_stream;
END equipment;

MODEL something REFINES equipment;
...
END something;
But library like this can work, but it doesn't help much for solving problems:
MODEL equipment;
inlet "in:" IS_A electron_stream;
outlet "out:" IS_A electron_stream;
V "potential:" IS_A voltage;
I "flow:" IS_A current;
END equipment;

MODEL something REFINES equipment;
...
END something;
Therefore, further implement is required on this.

== Work after GSOC ==

* Viewing block equations from right click - block properties is enabled, details in {{srcbranchdir|mike|pygtk/canvas/blockproperties.py}}

== Final Review ==

* How to use 'inout' port: (see {{srcbranchdir|mike|models/test/canvas/basic_electronics_model.a4c}} for detail)[[File:canvas_inout.png|thumb|alt='Inout' port is available in canvas|Connecting 'inout' port in canvas]]
** The resistor_basic model has normal 'inlet' and 'outlet' port. But the Ground model only has 'inout' port, which can be connected with any kinds of ports in canvas. The definition of 'inout' port is exactly the same as 'inlet' or 'outlet' ports. Part of the code is shown below:

<source lang=a4c>
MODEL Ground;
NOTES
'block' SELF {Ground}
'icon' SELF {ground.png}
'graphic' SELF {5,0-5,5
0,5-10,5
2,7-8,7
4,9-6,9}
'port_inout' SELF {inout:5,0}
END NOTES;
inout "inout:" IS_A electron_stream;
inout.V = 0 {volt};
END Ground;
</source>

* Piping system introduction:

* See previous logs for setup environment of my branch.

* Contact me via u5612799@anu.edu.au if you encounter problems / have questions.

* TODO List from me:
** Implement redo function in {{srcbranchdir|mike|pygtk/canvas/undo.py}}
** Improve quit check (quit_confirm) function in {{srcbranchdir|mike|pygtk/canvas/blocklist.py}}
** Improve functions of {{srcbranchdir|mike|models/test/canvas/basic_electronics_model.a4c}}
** Improve functions of {{srcbranchdir|mike|models/test/canvas/piping_system.a4c}}
** Improve potential and flow connectors in various files from {{srcbranchdir|mike|pygtk/canvas}}

== Screenshots ==
<gallery>
File:canvas_GUI.png|Canvas GUI
File:canvas_inout.png|'Inout' port is available in canvas
File:canvas_basic_elec.png|Basic electronic circuit simulation
File:canvas_block_properties.png|Block equation can be viewed from 'block properties'
File:canvas_quit_confirm.png|Warning dialog before quitting canvas
</gallery>

[[Category:ASCEND Contributors]]

Category:GSOC2016

2018-01-31T10:58:31Z

Mike:

Here are the student projects making up our [[GSOC2016]] activity, part of the [[GSOC|Google Summer of Code]] program.
[[Category:GSOC]]
[[Category:ASCEND Contributors]]

Category:GSOC

2018-01-31T10:55:51Z

Mike:

These pages relate to our participation in [http://code.google.com/soc/ Google Summer of Code], a programme where Google pays students to participate in free, open-source software projects.

Probably you want to see [[GSOC2018]].

[[Category:Development]]

GSOC2018

2018-01-31T10:52:31Z

Mike: tiny grammar

ASCEND is applying to participate in [https://summerofcode.withgoogle.com/ GSOC] in 2018. Please read below if you are interested in participating!

The following application guidelines are retained for future reference.

== General information ==

GSOC is a programme that lets students be paid for work that they do to contribute to an open-source software project. It is a competitive programme for which students must make themselves known to the software project directly, and then apply to Google for selection. Students who get involved well in advance of the deadlines usually have a much better chance of being selected. Some links for people wanting to learn about GSOC for possible future participation:
* [https://en.wikipedia.org/wiki/Google_Summer_of_Code general information about the programme (wikipedia)]
* [https://developers.google.com/open-source/gsoc/faq GSOC FAQs]
* [https://developers.google.com/open-source/gsoc/timeline timeline]
* '''[[Student projects]]''': our list of project ideas with ASCEND (or propose your own)
* [[:Category:GSOC]]: read about ASCEND projects/students with GSOC in previous years
* '''our application template''' is at the bottom of this page.

We'd like to encourage anyone interested in our project to get in contact with us, and make a proposal! In general, the best way to learn about ASCEND is first to actually try to use it: so, ''please, [[SvnInfo|get the code]], [[Building ASCEND|build it]], try writing some models'', ponder our [[student projects]] list, and make your proposal. If you would like to discuss any of this, you can [[Support|get in contact with us]].

Please note that to actually formally apply to participate in the GSOC, you must do so via the GSOC website, you don't apply to us.

== Ways to get involved ==

* read the [[ASCEND overview]] and understand what ASCEND actually does.
* download our 'trunk' code [[SvnInfo|using subversion]] then [[Building ASCEND|build it]], and then [https://lists.sourceforge.net/lists/listinfo/ascend-sim-users let us know] about any issues you come across. Try to help us fix those issues. If you want an overview of the code, see our [[Developer's Manual]].
* ''use'' ASCEND! write some models to solve some problems that you have come across in your coursework or elsewhere. Preferably they should be non-trival: simultaneous nonlinear equations, optimisation problems, dynamic problems, etc. Send us your completed models, and work to make them general and reusable. Make use of existing reusable models from our [[model library]] where possible. If we see someone who's actually worked out what ASCEND is and how to use it, we're much more likely to sit up and pay attention!
* read our [[:Category:Documentation|documentation]] and help us to improve it: this is a wiki, so anyone can edit it. (Note: because of endless spam, you have to first register and we have to manually review your submission, but if you look like you're a real human-being person thing, then we're happy to have you.)
* take a look at our [http://bugs.ascend4.org|bug tracker] and find a bug that you can fix, or a feature request that you can implement
* get onto our [https://lists.sourceforge.net/lists/listinfo/ascend-sim-users mailing list] and open a discussion on features you would like to see in ASCEND
* talk to your professor about ASCEND, and whether there might be ways to incorporate project work with ASCEND into your degree.
* you might like to try tackling some little example problems that we previously used as tests for our GSOC applicants: [[OpenMP Exercise]], [[ANTLR exercise]]. We'll update here if we manage to write any new example problems.

== Application template ==

'''''The following is the 'application template' that you can use when submitting your formal proposal to ASCEND via the GSOC website. Please check back here before the application deadline to ensure you have included all of the requested information. Please take care with formatting, and try to use a concise style.'''''

'''About you'''
* Name: full name (preferred 'friendly' name in brackets)
* Email:
* Location: country, city during coding period
* University: current university and course, year started, length, expected completion date.
** Please include an email address and website reference for a '''professor at your university''' whom we can contact to confirm your enrolment status if required.
* Skype ID: (if you have one)
* Are you subscribed to our [[Support|ascend-sim-users]] mailing list? YES/NO (we prefer YES!)
* Phone number: (optional)
* URL link to your CV: (optional)
* URL link to your personal blog/homepage: (optional)

'''Project proposal'''
* Project title as provided on the [[Student projects]] page (or something of your own)
* Then, a description of the project ''in your own words''. What do you think you will be able to achieve, and what will your approach be? Why did you choose this idea?
* What progress have you made already? This might be a more detailed plan, getting up and running, some initial coding, familiarising yourself with related tools, or some general bug-fixing or bug-reporting for ASCEND more broadly.

'''Milestones'''
* What are the goals of your project? Are they [https://en.wikipedia.org/wiki/SMART_criteria ''specific'', ''measurable'', ''achievable'', ''realistic'' and ''time-specific'']?
* Give a schedule, showing the order in which you will achieve the specified goals. If possible, show that you have discussed the plan with your proposed mentor.

'''Other commitments'''
* We expect our GSOC students to be online (we prefer Skype) and immediately contactable for at least 35 hours a week, working directly on their GSOC project. If you expect this to be difficult, or if you expect to work at odd hours, we want to know in advance.
* Note that we require an ''absolute minimum'' of a weekly email update from all our students.

'''Programming language experience/expertise'''
* Programming languages you have learnt, and how many lines of code, approximately, you have written in each.

'''Relevant experience'''
* List jobs, projects, courses etc that show that you have the required knowledge and experience for this project. Explain briefly how they relate to the project you are seeking.
* Only list things that are relevant, we don't want your whole CV.

'''Experience with ASCEND'''
* Is this your first contact with the ASCEND project?
* List or link to any code, patches, documentation or bug reports contributed to ASCEND or other projects.
* Please give us as much evidence as you can to show that you have got our code running on your machine -- compiled it from the source code yourself -- and that you've figured out how to use it independently. The more independent use that you can show, the better. If you've identified a bug, report it and link to your bug report. If you've written a new model, or some new code to add, tell us about it. The more you've done, the easier it is for us to trust in your ability to contribute.

'''Why ASCEND?'''
* If you can, say something insightful about the ASCEND project ''specifically'' -- something about our project that interests you more than others available in GSOC.

[[Category:GSOC]]

Student projects

2018-01-31T10:00:47Z

Mike: correct small typos

Welcome to [[Main Page|ASCEND]]! You might want to read our [[ASCEND overview|overview]] to learn a bit about our project, or read about our more general [[Development Activities]]. This page gives a long list of possible student projects with our project, which means potential [[GSOC2018]] projects, or possibly undergrad or post-grad research projects, such as for engineering final-year students. Our contact details are [[Support|here]].

'''Last updated Jan 2018.'''

= Recommended projects =

We have assigned '''priorities''' to these projects. All things being equal, we will choose students who propose high-priority projects. However, all things are not equal; if we receive a very strong proposal from a student who has done lots of preparatory work, then we will probably choose that student over a lower-quality proposal for a higher-priority project.

== Graphical flowsheet editor ==

Similar to the flowsheet editor in chemical process modelling software such as ASPEN, ASCEND has a [[canvas-based_modeller_for_ASCEND|Canvas-based modeller]] which is currently in development, and not yet quite usable. We would like to push this nice new interface closer to usability. The next step in the implementation, be believe, is to implement proper 'connector' logic, including annotation which which variables should be connected in a 'potential' sense (eg. voltage, temperature), and which which should be connected in a 'flow' sense (eg. current, energy). Connectors should be able to connect a number of related variables at once. Also it would be good to present documents/tutorials to users for solving practical problems. Before going ahead with this project, we would like to discuss implementation details with interested students.

* Contact person: [[John Pye]], [[User:Mike|Tengda (Mike) Han]]
* Level of difficulty: Medium
* Priority: Medium/High
* Languages: Python, possibly a small amount of C/C++
* Also useful: Cairo/PyGTK/PyGI, design patterns for GUI programming

== Parallel optimisation solvers for ASCEND ==

We would like to develop optimisation solvers for ASCEND using particle swarm optimisation (PSO) or a hybrid of PSO with gradient-based Newton solver methods. Such methods are amenable to parallelisation, and should be considerably faster for certain kinds of models with modern hardware. Connecting to an existing open-source solver would be preferred, but only if it makes good sense architecturally. Before starting, we would like to discuss possible implementation approaches. It's important to note that current ASCEND is not thread-safe, so care may be required depending on the approach that is taken.

* Contact: [[John Pye]], [[Ben Allan]]
* Languages: C
* Difficulty: Medium-High
* Priority: High

== FPROPS ==

Our [[FPROPS]] fluid properties library within ASCEND is used to calculate the properties of pure fluids (enthalpy, pressure, temperature, density, viscosity, conductivity, etc) with high accuracy. We would like to extend its capabilites in various ways: (1) add support for mixtures, (2) add support for more equations of state, especially cubic equations of state such as Redlich-Kwong and others, (3) add support for incompressible liquids, (4) add support for humid air calculations, (4) demonstrate its use in flash, heat exchanger and reactor models in ASCEND. This project requires someone with background in engineering thermodynamics (for example, having studied the [http://www.amazon.com/dp/0471661740 Sandler book] or similar), because the theory from that book is a necessary starting point for the project.

* Contact: [[Mahesh Venkataraman]], [[John Pye]], [[Krishnan Chittur]]
* Languages: C and maybe a small amount of Python
* Must know: engineering thermodynamics (eg. the [http://www.amazon.com/dp/0471661740 Sandler book])
* Difficult: Medium
* Priority: High

== Gibbs equilibrium reactor model ==

We would like to implement a robust tool for calculating reaction equilibrium using Gibbs free energy minimisation. This needs to be done in a way that is compatible with the ASCEND approach to declaring [[MODEL]]s etc., and should make use of [[FPROPS]] for the calculation of the properties of each component. We have some sample code in MATLAB; a first step might be to convert that code to C and connect it to FPROPS. We will need to simultaneously discuss how to interface to the code to ASCEND so that it can be used in the context of flexible modelling of chemical process flowsheets.

* Contact person: [[Mahesh Venkataraman]], [[John Pye]]
* Level of difficulty: Medium
* Must know: engineering thermodynamics (eg the [http://www.amazon.com/dp/0471661740 Sandler book])
* Priority: Medium/High
* Languages: C

== CAPE-OPEN thermodynamics ==

[http://www.colan.org/ CAPE-OPEN] is a well-documented API for evaluating thermodynamic properties of mixtures, running flash calculations, etc, which exists in the chemical process simulation community. In this project, we'd like to develop a first proof-of-concept integration of CAPE-OPEN into ASCEND. It is suggested that we might use the CAPE-OPEN thermodynamics library provided by [http://dwsim.inforside.com.br/wiki/index.php?title=CAPE-OPEN the DWSIM project], although other possibilities exist. Importantly, we need this approach to work on Linux as well as Windows, and this may complicate matters. However, on the whole, it should be possible to achieve this integration in a relatively straightforward way using our support for external functions (eg see [[writing ASCEND external relations in C]]). Having CAPE-OPEN support with greatly increase ASCEND's access to range of high-quality thermodynamic property engines, which would be very helpful in improving the usefulness of our code.

* Contact person: [[John Pye]], [[Mahesh Venkataraman]], [[Krishnan Chittur]]
* Level of difficulty: Medium (/ Low?)
* Must know: chemical engineering thermodynamics (eg the [http://www.amazon.com/dp/0471661740 Sandler book])
* Priority: Medium/High
* Languages: C, possibly others for 'gluing' to the CAPE-OPEN DLLs/COM objects

== Dynamic modelling improvements ==

This project would build on the progress with [[dynamic modelling]] by [[User:Ksenija|Ksenija]] in GSOC2012-2013. We would like to improve our new [[EVENT]] syntax and extend its support to a range of problem types not yet supported, such as periodic events, and make further changes to the ASCEND language to make dynamic modelling more 'natural'. We would like to work on the efficiency of the [[ODE]]/[[DAE]] engines, to ensure that integrator restarts after boundaries are as efficient as possible.

* Contact person: [[John Pye]]
* Level of difficulty: High
* Priority: High
* Must know: numerical methods
* Languages: C, plus possibly some use of lex/yacc

== Debugging tools for DAE modelling ==

We would like to implement tools that make it easier to determine degrees-of-freedom problems for initial value problems, and possibly implement index reduction into ASCEND. One possible algorithm is that by Soares and Secchi (see [http://cepac.cheme.cmu.edu/pasi2011/library/secchi/Soares_Secchi_Dycops-2007_p217.pdf Soares_Secchi_Dycops-2007] or (somewhat different) {{doi|10.1016/S1570-7946(07)80063-0}}).

* Contact person [[John Pye]]
* Level of difficulty: High
* Priority: Medium
* Must know: numerical methods, differential equations, graph theory
* Languages: C

== Improvements to the Conditional Modelling syntax ==

ASCEND provides support for [[Conditional modelling]] in the form of language constructs and a solver called [[CMSlv]]. Unfortunately the syntax available for conditional modelling is unintuitive. It could be improved by a student willing to delve into the dark corners of the ASCEND compiler and willing to learn about the Flex and Bison parser/compiler tools. Further work on this project could include a rigorous test-suite to demonstrate that all aspects of the conditional model parser and corresponding solver are working OK. Additional further might include enhancements to the graphical interface to make it more obvious to the user when parts of the model are switched on and off as a result of changes in IF or WHEN statements, or alternatively completion of the conditional modelling support for the dynamic modelling solver [[IDA]]. This is another item that would benefit from a [[New Compiler]] effort.

* Contact person: [[John Pye]], [[Art Westerberg]]
* Level of difficulty: medium
* Priority: High
* Languages: Flex/Bison, C

= Other projects =

The following list contains a range of projects that we consider either harder to tackle, or lower priority, or which require very particular skills.

== Python bindings rewrite ==

We would like to review and improve the way that ASCEND accesses its low-level C functionality from Python. Currently this is done via C++ using the [http://www.swig.org SWIG] interface generator. Our preference is probably to keep using SWIG, but to eliminate the C++ layer. Alternatively, a different type of interfacing tool like Cython could be used instead. The new wrapping/langugage bindings would need to be tested via a set of test suites, and program examples in Python provided. It would not be necessary to translate the GUI code to use this new wrapper, although that would certainly be desirable.

* Contact: [[John Pye]]
* Languages: C, Python, C++, SWIG
* Difficulty: Medium
* Priority: Medium

== MSYS2 ==

We would like to implement a new build process for ASCEND for Windows, based on the use of [https://msys2.github.io/ MSYS2]. MSYS2 is a command-line environment similar to Linux. It offers the usual GCC compilers etc, plus a package manager with pre-compiled versions of many of our dependency libraries and tools. This project would require (1) modifying current SCons build files so that they work correctly with MSYS2 (compared to older MSYS), (2) ensuring that all required dependencies are also available in MSYS2 and (3) producing a new installer for ASCEND, by updating our current NSIS-based scripts, that makes use of the MSYS2 binaries built in 1 and 2.

* Contact person: [[John Pye]]
* Languages: Python, C, NSIS
* Must know: usability principles
* Level of difficulty: Low/Medium
* Priority: High

== GTK3/Python3 ==

We have already done quite a bit of work (eg [[User:Adrian]]) on adapting ASCEND to work with GTK3 (PyGI, PyGTK3). Next we need to update ASCEND so that it works correctly with Python3. This will require some work using SWIG to update our Python wrapper to work with Python3. It will also require some changes to the Python GUI (code in {{srcdir|pygtk}}. Finally, it is very important to check that the build and install processes work correctly with Python3 on both Windows and Linux as a minimum.

* Contact: [[John Pye]]
* Languages: Python, SWIG, possibly some C/C++.
* Difficulty: Low/Medium
* Priority: High

== Automated parameter-setting for dynamic models ==

With the addition of [[SOLVE]], [[SOLVER]] and [[OPTION]] statements to the ASCEND language, we now have a way to specify all the necessary parameters for most of the ASCEND solvers like [[QRSlv]], [[IPOPT]] and others. However, this implementation doesn't work with our [[ODE]]/[[DAE]] solvers like [[LSODE]] and [[IDA]]. This project would involve extending the ASCEND language in a way that dynamic models could be easily initialised and solved using statements in [[METHOD]] syntax. A careful review of the [[OPTION]] syntax is also required, as it appears that in some cases the current approach fails to pass through parameters if the solver has already been connected to the system. There is no tough mathematics involved in this project; mostly it's about data structures and information-passing, but efficient software design will be very important.

* Contact person: [[John Pye]]
* Very helpful: experience on a large software project (or software engineering studies)
* Level of difficulty: Medium/high
* Languages: C, Python

== Automated connector routing for the canvas-based modeller ==

When working on big simulation models, line routing can be annoying and tedious, but with a sufficiently clever constraint-based solver, algorithms can be used to automate the task, leaving only minor tweaking required to complete a diagram. Our collaborator on the [[canvas-based_modeller_for_ASCEND|canvas-based modeller]], [[Arjan Molenaar]], [https://github.com/amolenaar/adaptagrams has been working] to integrate Michael Wybrow's [http://adaptagrams.sourceforge.net/ adaptagrams] library into Gaphas, to add support for automatic line routing. At this stage he has got partial Python bindings for the needed parts of adaptagrams, but not plan yet exists for how that will be incorporated into Gaphas or thence to our canvas-based modeller. This project would require someone with good Python skills to work in Gaphas as well as ASCEND to development this functionality.

* Contact person: [[John Pye]] and Arjan Molenaar would hopefully help out as an informal mentor
* Level of difficulty: Medium
* Priority: Medium
* Languages: C

== Bug Squashing ==

We've got a [http://ascendbugs.cheme.cmu.edu/ big long list] of bugs and feature requests (as well as [http://ascendbugs.cheme.cmu.edu/roadmap_page.php a shortlist]) that a student could certainly work on with success. Many of the bugs can be fairly easily fixed and just need a little time. Someone with the right C/C++/Python programming background plus understanding on numerical methods and hopefully some understanding of compiler design and/or GUI design could really make a difference for us.

* Contact person: [[John Pye]]
* Level of difficulty: variable, depends on the bugs you choose to fix
* Must know: numerical methods
* Languages: primarily C, and then possibly Python, C++, Flex/Bison, SWIG, Tcl/Tk, PyGTK,...
* Priority: Medium/High

== Persistence of modelling results ==

Currently, ASCEND models are loaded and solved afresh each time. But sometimes, it can take a bit of fiddling to achieve solution of a model. In these cases, it would be useful to be able to save the model state and load it again into ASCEND. A coherent proposal for how to do this needs to be prepared, in discussion with the ASCEND team, by a student who would like to work in this area. Because this task involved loading and saving model state, it is proposed that it could also incorporate more general data export functionality, eg to export whole/partial model results to a CSV or tab-delimited file, for use with other tools. How this system would work with 'observers' and 'integrator' output is an open question. See also [[Saving and restoring model state]]. Especially important that the design of this component would work nicely with the new [[canvas-based modeller for ASCEND]].

* Contact person: [[John Pye]]
* Level of difficulty: Low-medium
* Languages: C, Python, possibly some Tcl.
* Priority: Medium

== Packaging for Mac ==

We want to get ASCEND working for Mac! We previously did a lot of the work (see [[Porting to Mac]]), but since then Python3 and GTK3 have become commonplace, and we also need to develop an ASCEND bundle/installer/disk-image that feels nice and Mac-ish, but doesn't cause too much disruption to the overall codebase. One key challenge is to provide suitable Apple Event bindings so that models can be opened using the ASCEND GUI.

* Contact person: [[John Pye]], [[Art Westerberg]]
* Level of difficulty: low-medium
* Priority: Medium
* Languages: Python, C, and a fair bit of general Mac OSX knowhow

== New Compiler ==

If you've got a strong background or interest in designing parsers/lexers/compilers, we'd be interested to discuss possible ways to write a new compiler for the ASCEND language. The original ASCEND compiler uses Flex/Bison, but perhaps we can make something more efficient and easier to maintain using more modern tools, perhaps such as ANTLR. See also [[New Compiler]]

* Contact person: [[Ben Allan]], [[John Pye]]
* Level of difficulty: very high
* Languages: flexible, would need to interface with current instance hierarchy C code
* Priority: Medium

== Model Export Engine Experiments (MEEE!) ==

A number of the other projects on this page are concerned with converting a model into some format appropriate for use with another tool. There are actually two kinds of objects both ambiguously known as ASCEND models:

* an ascend TypeDescription: a list of statements that must be interpreted somehow to derive a data tree (Instance) in memory.
* an Instance data tree (which, in principle, may contain references to unexecuted statements from the TypeDescription or may be 'completed').

Potential approaches:

* Conversion of C TypeDescriptions to equivalent classes in some other language is the most general form of model reuse, but requires careful implementation of the conversion operation. A general solution would be to create, or expose in a convenient form, visitor functionality over a self-consistent list of related TypeDescriptions for type-translation plugins to convert to other languages. In the compiler science world, the ascend TD is most related to an AST.
* Conversion of ascend model source via an independent parser to another language. This approach 'reinvents' the ASCEND AST and grammar, but may then be much more translator friendly-- e.g. Java or other tools could be used for implementation with no direct reference to the existing C code base.
* Define a visitor API for conversion of instance data structures to classes in other languages. These classes may or may not look anything like the original object-oriented models. Note that conversions of this sort to flat-file data storage formats (for reloading in ascend later) and to object-free (flat) modeling languages are in the ascend code base already.

See also: Persistence, Openoffice below.

* Contact person: [[Ben Allan]], [[John Pye]]
* Level of difficulty: medium
* Language: C / ANTLR / others
* Priority: Medium/Low

== Internationalisation ==

ASCEND has some bugs when used in locales that use the comma ',' as the decimal point separator. Furthermore, its user interface is in english only, with the exception of some standard menus that GTK+ provides translations for. This project would work towards internationalising ASCEND, starting with solving the decimal point problem, then translating the Python GUI, then moving on into the C library part of ASCEND. It would not be intended that the modelling language itself would be translated, though, nor would the decimal point separator in model files change from the default "." -- the same model files need to work for everyone.

* Contact person: [[John Pye]]
* Level of difficulty: low
* Languages: Python, C
* Priority: Low

== Your Own Ideas ==

There are many other areas of possible work on ASCEND, including those from our long list of current and future [[Development Activities]]. Feel free to discuss other possible ideas with us!

* Contact person: write to the 'users' mailing list (see [[Support]]).

[[Category:Development]]

User:Mike

2017-10-11T07:31:29Z

Mike:

Student projects

2017-02-25T08:57:07Z

Mike: /* Graphical flowsheet editor */

Welcome to [[Main Page|ASCEND]]! You might want to read our [[ASCEND overview|overview]] to learn a bit about our project, or read about our more general [[Development Activities]]. This page gives a long list of possible student projects with our project, which means potential [[GSOC2017]] projects, or possibly undergrad or post-grad research projects, such as for engineering final-year students. Our contact details are [[Support|here]].

'''Last updated Feb 2017.'''

= Recommended projects =

We have assigned '''priorities''' to these projects. All things being equal, we will choose students who propose high-priority projects. However, all things are not equal; if we receive a very strong proposal from a student who has done lots of preparatory work, then we will probably choose that student over a lower-quality proposal for a higher-priority project.

== Graphical flowsheet editor ==

Similar to the flowsheet editor in chemical process modelling software such as ASPEN, ASCEND has a [[canvas-based_modeller_for_ASCEND|Canvas-based modeller]] which is currently in development, and not yet quite usable. We would like to push this nice new interface closer to usability. The next step in the implementation, be believe, is to implement proper 'connector' logic, including annotation which which variables should be connected in a 'potential' sense (eg voltage, temperature), and which which should be connected in a 'flow' sense (eg current, energy). Connectors should be able to connect a number of related variables at once. Also it would be good to present documents/tutorials to users for solving practical problems. Before going ahead with this project, we would like to discuss implementation details with interested students.

* Contact person: [[John Pye]], [[User:Mike|Tengda (Mike) Han]]
* Level of difficulty: Medium
* Priority: Medium/High
* Languages: Python, possibly a small amount of C/C++
* Also useful: Cairo/PyGTK/PyGI, design patterns for GUI programming

== Parallel optimisation solvers for ASCEND ==

We would like to develop optimisation solvers for ASCEND using particle swarm optimisation (PSO) or a hybrid of PSO with gradient-based Newton solver methods. Such methods are amenable to parallelisation, and should be considerably faster for certain kinds of models with modern hardware. Connecting to an existing open-source solver would be preferred, but only if it makes good sense architecturally. Before starting, we would like to discuss possible implementation approaches. It's important to note that current ASCEND is not thread-safe, so care may be required depending on the approach that is taken.

* Contact: [[John Pye]], [[Ben Allan]]
* Languages: C
* Difficulty: Medium-High
* Priority: High

== FPROPS ==

Our [[FPROPS]] fluid properties library within ASCEND is used to calculate the properties of pure fluids (enthalpy, pressure, temperature, density, viscosity, conductivity, etc) with high accuracy. We would like to extend its capabilites in various ways: (1) add support for mixtures, (2) add support for more equations of state, especially cubic equations of state such as Redlich-Kwong and others, (3) add support for incompressible liquids, (4) add support for humid air calculations, (4) demonstrate its use in flash, heat exchanger and reactor models in ASCEND. This project requires someone with background in engineering thermodynamics (for example, having studied the [http://www.amazon.com/dp/0471661740 Sandler book] or similar), because the theory from that book is a necessary starting point for the projct.

* Contact: [[Mahesh Venkataraman]], [[John Pye]], [[Krishnan Chittur]]
* Languages: C and maybe a small amount of Python
* Must know: engineering thermodynamics (eg the [http://www.amazon.com/dp/0471661740 Sandler book])
* Difficult: Medium
* Priority: High

== Gibbs equilibrium reactor model ==

We would like to implement a robust tool for calculating reaction equilibrium using Gibbs free energy minimisation. This needs to be done in a way that is compatible with the ASCEND approach to declaring [[MODEL]]s etc., and should make use of [[FPROPS]] for the calculation of the properties of each component. We have some sample code in MATLAB; a first step might be to convert that code to C and connect it to FPROPS. We will need to simultaneously discuss how to interface to the code to ASCEND so that it can be used in the context of flexible modelling of chemical process flowsheets.

* Contact person: [[Mahesh Venkataraman]], [[John Pye]]
* Level of difficulty: Medium
* Must know: engineering thermodynamics (eg the [http://www.amazon.com/dp/0471661740 Sandler book])
* Priority: Medium/High
* Languages: C

== CAPE-OPEN thermodynamics ==

[http://www.colan.org/ CAPE-OPEN] is a well-documented API for evaluating thermodynamic properties of mixtures, running flash calculations, etc, which exists in the chemical process simulation community. In this project, we'd like to develop a first proof-of-concept integration of CAPE-OPEN into ASCEND. It is suggested that we might use the CAPE-OPEN thermodynamics library provided by [http://dwsim.inforside.com.br/wiki/index.php?title=CAPE-OPEN the DWSIM project], although other possibilities exist. Importantly, we need this approach to work on Linux as well as Windows, and this may complicate matters. However, on the whole, it should be possible to achieve this integration in a relatively straightforward way using our support for external functions (eg see [[writing ASCEND external relations in C]]). Having CAPE-OPEN support with greatly increase ASCEND's access to range of high-quality thermodynamic property engines, which would be very helpful in improving the usefulness of our code.

* Contact person: [[John Pye]], [[Mahesh Venkataraman]], [[Krishnan Chittur]]
* Level of difficulty: Medium (/ Low?)
* Must know: chemical engineering thermodynamics (eg the [http://www.amazon.com/dp/0471661740 Sandler book])
* Priority: Medium/High
* Languages: C, possibly others for 'gluing' to the CAPE-OPEN DLLs/COM objects

== Dynamic modelling improvements ==

This project would build on the progress with [[dynamic modelling]] by [[User:Ksenija|Ksenija]] in GSOC2012-2013. We would like to improve our new [[EVENT]] syntax and extend its support to a range of problem types not yet supported, such as periodic events, and make further changes to the ASCEND language to make dynamic modelling more 'natural'. We would like to work on the efficiency of the [[ODE]]/[[DAE]] engines, to ensure that integrator restarts after boundaries are as efficient as possible.

* Contact person: [[John Pye]]
* Level of difficulty: High
* Priority: High
* Must know: numerical methods
* Languages: C, plus possibly some use of lex/yacc

== Debugging tools for DAE modelling ==

We would like to implement tools that make it easier to determine degrees-of-freedom problems for initial value problems, and possibly implement index reduction into ASCEND. One possible algorithm is that by Soares and Secchi (see [http://cepac.cheme.cmu.edu/pasi2011/library/secchi/Soares_Secchi_Dycops-2007_p217.pdf Soares_Secchi_Dycops-2007] or (somewhat different) {{doi|10.1016/S1570-7946(07)80063-0}}).

* Contact person [[John Pye]]
* Level of difficulty: High
* Priority: Medium
* Must know: numerical methods, differential equations, graph theory
* Languages: C

== Improvements to the Conditional Modelling syntax ==

ASCEND provides support for [[Conditional modelling]] in the form of language constructs and a solver called [[CMSlv]]. Unfortunately the syntax available for conditional modelling is unintuitive. It could be improved by a student willing to delve into the dark corners of the ASCEND compiler and willing to learn about the Flex and Bison parser/compiler tools. Further work on this project could include a rigorous test-suite to demonstrate that all aspects of the conditional model parser and corresponding solver are working OK. Additional further might include enhancements to the graphical interface to make it more obvious to the user when parts of the model are switched on and off as a result of changes in IF or WHEN statements, or alternatively completion of the conditional modelling support for the dynamic modelling solver [[IDA]]. This is another item that would benefit from a [[New Compiler]] effort.

* Contact person: [[John Pye]], [[Art Westerberg]]
* Level of difficulty: medium
* Priority: High
* Languages: Flex/Bison, C

= Other projects =

The following list contains a range of projects that we consider either harder to tackle, or lower priority, or which require very particular skills.

== Python bindings rewrite ==

We would like to review and improve the way that ASCEND accesses its low-level C functionality from Python. Currently this is done via C++ using the [http://www.swig.org SWIG] interface generator. Our preference is probably to keep using SWIG, but to eliminate the C++ layer. Alternatively, a different type of interfacing tool like Cython could be used instead. The new wrapping/langugage bindings would need to be tested via a set of test suites, and program examples in Python provided. It would not be necessary to translate the GUI code to use this new wrapper, although that would certainly be desirable.

* Contact: [[John Pye]]
* Languages: C, Python, C++, SWIG
* Difficulty: Medium
* Priority: Medium

== MSYS2 ==

We would like to implement a new build process for ASCEND for Windows, based on the use of [https://msys2.github.io/ MSYS2]. MSYS2 is a command-line environment similar to Linux. It offers the usual GCC compilers etc, plus a package manager with pre-compiled versions of many of our dependency libraries and tools. This project would require (1) modifying current SCons build files so that they work correctly with MSYS2 (compared to older MSYS), (2) ensuring that all required dependencies are also available in MSYS2 and (3) producing a new installer for ASCEND, by updating our current NSIS-based scripts, that makes use of the MSYS2 binaries built in 1 and 2.

* Contact person: [[John Pye]]
* Languages: Python, C, NSIS
* Must know: usability principles
* Level of difficulty: Low/Medium
* Priority: High

== GTK3/Python3 ==

We have already done quite a bit of work (eg [[User:Adrian]]) on adapting ASCEND to work with GTK3 (PyGI, PyGTK3). Next we need to update ASCEND so that it works correctly with Python3. This will require some work using SWIG to update our Python wrapper to work with Python3. It will also require some changes to the Python GUI (code in {{srcdir|pygtk}}. Finally, it is very important to check that the build and install processes work correctly with Python3 on both Windows and Linux as a minimum.

* Contact: [[John Pye]]
* Languages: Python, SWIG, possibly some C/C++.
* Difficulty: Low/Medium
* Priority: High

== Automated parameter-setting for dynamic models ==

With the addition of [[SOLVE]], [[SOLVER]] and [[OPTION]] statements to the ASCEND language, we now have a way to specify all the necessary parameters for most of the ASCEND solvers like [[QRSlv]], [[IPOPT]] and others. However, this implementation doesn't work with our [[ODE]]/[[DAE]] solvers like [[LSODE]] and [[IDA]]. This project would involve extending the ASCEND language in a way that dynamic models could be easily initialised and solved using statements in [[METHOD]] syntax. A careful review of the [[OPTION]] syntax is also required, as it appears that in some cases the current approach fails to pass through parameters if the solver has already been connected to the system. There is no tough mathematics involved in this project; mostly it's about data structures and information-passing, but efficient software design will be very important.

* Contact person: [[John Pye]]
* Very helpful: experience on a large software project (or software engineering studies)
* Level of difficulty: Medium/high
* Languages: C, Python

== Automated connector routing for the canvas-based modeller ==

When working on big simulation models, line routing can be annoying and tedious, but with a sufficiently clever constraint-based solver, algorithms can be used to automate the task, leaving only minor tweaking required to complete a diagram. Our collaborator on the [[canvas-based_modeller_for_ASCEND|canvas-based modeller]], [[Arjan Molenaar]], [https://github.com/amolenaar/adaptagrams has been working] to integrate Michael Wybrow's [http://adaptagrams.sourceforge.net/ adaptagrams] library into Gaphas, to add support for automatic line routing. At this stage he has got partial Python bindings for the needed parts of adaptagrams, but not plan yet exists for how that will be incorporated into Gaphas or thence to our canvas-based modeller. This project would require someone with good Python skills to work in Gaphas as well as ASCEND to development this functionality.

* Contact person: [[John Pye]] and Arjan Molenaar would hopefully help out as an informal mentor
* Level of difficulty: Medium
* Priority: Medium
* Languages: C

== Bug Squashing ==

We've got a [http://ascendbugs.cheme.cmu.edu/ big long list] of bugs and feature requests (as well as [http://ascendbugs.cheme.cmu.edu/roadmap_page.php a shortlist]) that a student could certainly work on with success. Many of the bugs can be fairly easily fixed and just need a little time. Someone with the right C/C++/Python programming background plus understanding on numerical methods and hopefully some understanding of compiler design and/or GUI design could really make a difference for us.

* Contact person: [[John Pye]]
* Level of difficulty: variable, depends on the bugs you choose to fix
* Must know: numerical methods
* Languages: primarily C, and then possibly Python, C++, Flex/Bison, SWIG, Tcl/Tk, PyGTK,...
* Priority: Medium/High

== Persistence of modelling results ==

Currently, ASCEND models are loaded and solved afresh each time. But sometimes, it can take a bit of fiddling to achieve solution of a model. In these cases, it would be useful to be able to save the model state and load it again into ASCEND. A coherent proposal for how to do this needs to be prepared, in discussion with the ASCEND team, by a student who would like to work in this area. Because this task involved loading and saving model state, it is proposed that it could also incorporate more general data export functionality, eg to export whole/partial model results to a CSV or tab-delimited file, for use with other tools. How this system would work with 'observers' and 'integrator' output is an open question. See also [[Saving and restoring model state]]. Especially important that the design of this component would work nicely with the new [[canvas-based modeller for ASCEND]].

* Contact person: [[John Pye]]
* Level of difficulty: Low-medium
* Languages: C, Python, possibly some Tcl.
* Priority: Medium

== Packaging for Mac ==

We want to get ASCEND working for Mac! We previously did a lot of the work (see [[Porting to Mac]]), but since then Python3 and GTK3 have become commonplace, and we also need to develop an ASCEND bundle/installer/disk-image that feels nice and Mac-ish, but doesn't cause too much disruption to the overall codebase. One key challenge is to provide suitable Apple Event bindings so that models can be opened using the ASCEND GUI.

* Contact person: [[John Pye]], [[Art Westerberg]]
* Level of difficulty: low-medium
* Priority: Medium
* Languages: Python, C, and a fair bit of general Mac OSX knowhow

== New Compiler ==

If you've got a strong background or interest in designing parsers/lexers/compilers, we'd be interested to discuss possible ways to write a new compiler for the ASCEND language. The original ASCEND compiler uses Flex/Bison, but perhaps we can make something more efficient and easier to maintain using more modern tools, perhaps such as ANTLR. See also [[New Compiler]]

* Contact person: [[Ben Allan]], [[John Pye]]
* Level of difficulty: very high
* Languages: flexible, would need to interface with current instance hierarchy C code
* Priority: Medium

== Model Export Engine Experiments (MEEE!) ==

A number of the other projects on this page are concerned with converting a model into some format appropriate for use with another tool. There are actually two kinds of objects both ambiguously known as ASCEND models:

* an ascend TypeDescription: a list of statements that must be interpreted somehow to derive a data tree (Instance) in memory.
* an Instance data tree (which, in principle, may contain references to unexecuted statements from the TypeDescription or may be 'completed').

Potential approaches:

* Conversion of C TypeDescriptions to equivalent classes in some other language is the most general form of model reuse, but requires careful implementation of the conversion operation. A general solution would be to create, or expose in a convenient form, visitor functionality over a self-consistent list of related TypeDescriptions for type-translation plugins to convert to other languages. In the compiler science world, the ascend TD is most related to an AST.
* Conversion of ascend model source via an independent parser to another language. This approach 'reinvents' the ASCEND AST and grammar, but may then be much more translator friendly-- e.g. Java or other tools could be used for implementation with no direct reference to the existing C code base.
* Define a visitor API for conversion of instance data structures to classes in other languages. These classes may or may not look anything like the original object-oriented models. Note that conversions of this sort to flat-file data storage formats (for reloading in ascend later) and to object-free (flat) modeling languages are in the ascend code base already.

See also: Persistence, Openoffice below.

* Contact person: [[Ben Allan]], [[John Pye]]
* Level of difficulty: medium
* Language: C / ANTLR / others
* Priority: Medium/Low

== Internationalisation ==

ASCEND has some bugs when used in locales that use the comma ',' as the decimal point separator. Furthermore, its user interface is in english only, with the exception of some standard menus that GTK+ provides translations for. This project would work towards internationalising ASCEND, starting with solving the decimal point problem, then translating the Python GUI, then moving on into the C library part of ASCEND. It would not be intended that the modelling language itself would be translated, though, nor would the decimal point separator in model files change from the default "." -- the same model files need to work for everyone.

* Contact person: [[John Pye]]
* Level of difficulty: low
* Languages: Python, C
* Priority: Low

== Your Own Ideas ==

There are many other areas of possible work on ASCEND, including those from our long list of current and future [[Development Activities]]. Feel free to discuss other possible ideas with us!

* Contact person: write to the 'users' mailing list (see [[Support]]).

[[Category:Development]]

User:Mike

2016-08-31T03:41:18Z

Mike: /* Screenshots */

[[Category:GSOC2016]]

Name: Tengda Han ([https://en.wikipedia.org/wiki/Chinese_characters 韩腾达]) (Mike)

University: [http://www.anu.edu.au/ ANU]

Email: u5612799@anu.edu.au

Summary: I did [[GSOC2016]] for ASCEND. I optimized GUI of Canvas, fixed bugs, developed canvas models and improved canvas language.

* Browse my code here: {{srcbranchdir|mike|}}
* Check out my code using <tt>svn co http://svn.ascend4.org/branches/mike</tt>

== Discussion notes of 12 May 2016 ==

To get the canvas GUI running in the trunk code, I used:

python ~/ascend/trunk/pygtk/canvas/canvas.py

== May 12 to May 22 ==

* Set development environment and play with canvas.

* Find a problem about module 'ascpy' in my branch, which cannot be found in canvas.py.

* But when I run canvas.py of main trunk, module 'ascpy' can be found, but another error is called:'''libascend.so.1: cannot open shared object file: No such file or directory'''

== Discussion notes of 23 May 2016 ==

* cannot find module 'ascpy' is because I need to compile by

scons -j4

* set paths properly before run canvas.py:

export LD_LIBRARY_PATH=~/Desktop/ascend_mike/mike/:$LD_LIBRARY_PATH
export PYTHONPATH=~/Desktop/ascend_mike/mike/models/johnpye/fprops/python:$PYTHONPATH

* find a bug of Adrian's branch, which is, when run the solver, ascend kills the background terminal. Trying different ubuntu system may work.

== May 23 to May 29 ==

* Tested Adrian's branch on ubuntu 16.04 LTS. Previous bug doesn't exist (ascend kills the terminal)

* Try to understand Gaphas and libavoid.

* Link 'libavoid' on ASCEND wiki has 404 error.

* When 'scons' ASCEND in Ubuntu16.04, SWIG error comes. [https://github.com/georgyberdyshev/ascend/commit/6962ef6c2ca36ff6cfff85e98c2daeac82619b82/ sulution here]

== Discussion notes of 30 May 2016 ==

* When try to run canvas.py, should set PYTHONPATH to

ascend_trunk/trunk/model/johnpye/fprops/python

* For Adrian's version
::canvas.py doesn't work because of
Error: sys.path must be a list of directory names
::Reason: installed python-gaphas uses gtk2. But we require gtk3 branch of gaphas, Solution:
cd ~/desired directory
git clone https://github.com/amolenaar/gaphas
git checkout gtk3
git pull
sudo python setup.py install
::However, after canvas.py pops up, ''TypeError: Couldn't find conversion for foreign struct 'cairo.Context''' occurs when click on blank canvas

== May 30 to June 5 ==

* Solved ''TypeError: Couldn't find conversion for foreign struct 'cairo.Context' '' by

sudo apt-get python-gi-cairo

[http://packages.ubuntu.com/trusty/python-gi-cairo This package] is a Python Cairo bindings for the GObject library

* If problems occur when installing gaphas by

sudo apt-get install python-gaphas

[http://www.installion.co.uk/ubuntu/precise/universe/p/python-gaphas/install/index.html/ Check the universe repository] before installation may help

* Undo button works (finishing the work of Adrian), redo haven't been implemented yet.

== Discussion notes of June 6 2016 ==

* Buttons now have labels. By adding ''tb.set_style(Gtk.ToolbarStyle.BOTH)'' after ''tb = Gtk.Toolbar()''

* Delete unnecessary .svg image files in {{srcbranchdir|mike|pygtk/canvas}} only leave defaultblock.svg

* Block icons should be generated by strings, instead of load image. Example: {{srcbranch|mike|models/test/canvas/brayton_fprops_rachel.a4c}}

* Currently svn version is updated to {{changeset|3110}}

* I can improve blocks, firstly to make sure they can be properly solved in canvas.

== June 6 to June 13 ==

* models in {{srcbranch|mike|models/test/canvas/basic_electronics_model.a4c}} have been updated.

* Problems found: every time after using the model in canvas, a '.svg' file of that model will be generated.

== June 13 to June 28 ==

* Working on redo function. Implement redo function in {{srcbranch|mike|pygtk/canvas/undo.py}}

* Fix a bug that rankine_canvas.a4c in {{srcbranch|mike|models/test/canvas/}} cannot run in canvas

* Fix a bug that rankine_stream.a4c in {{srcbranch|mike|models/test/canvas/}} cannot run in canvas

* Fix a bug that rankine_stream_v2.a4c in {{srcbranch|mike|models/test/canvas/}} cannot run in canvas

* Fix a bug that ammonia_synthesis_v2.a4c in {{srcbranch|mike|models/test/canvas/}} cannot run in canvas

* GUI update: Load Library (Ctrl+L) is enabled from menu bar

* GUI update: Correct labels in Block Properties Dialog

== June 29 to July 10 ==

* Fix a bug when adjusting Error/Status Reporter Console

* Rotate(Ctrl+R) and Flip(Ctrl+F) operation is added to menu bar, and keyboard shortcuts of them are enabled.

* Correct current value (I) in running results from {{srcbranch|mike|models/test/canvas/basic_electronics_model.a4c}} library.

* Find a bug: In basic_electronics_model.a4c, when connect 2 ports of T-piece/Branch together and run, Canvas will quit.

* An Error occurs when load canvas files because blocks with same name exist. Solution: 1. add a checker before 'run' or 'save'. 2. avoid reduplicate names when generating blocks.

* Also, a warning 'CompareStatements called with unknown statement' always appears when load files, but seems don't affect the result.

* Add reporter for loading libraries and files.

* Errors including line number can be shown on canvas when loading is unsuccessful.

* Update information in 'Help' Menu

== Discussion notes of July 11 2016 ==

* Automatically generating .svg files when load libraries: save these images into ~/.ascend/tmp

* Preference of units should be improved: modify pygtk/preference.py

* Warning should be displayed when ports not connected

* Models with degree of freedom should not be solved. Warning should be displayed

* In 'Block Properties', equations of blocks should be displayed

== July 11 to July 20 ==

* Correct syntax error in some files

* Improving Block Properties to display equations, by editing relating python files and glade files.

* Warning Dialog added when load new libraries with canvas items existing.

* Warning Dialog added when exiting without saving canvas (still need improve).

== Discussion notes for July 20 2016 ==

* For equation display, some paths may be valuable to check: asclibrary - get module types - library.h - type.h - ismodel(); ascend/compiler - type.descio.h - writedefinition.

* Next Step: Create a library for piping system. Read Mechanics of Fluids. Be careful with flow network & over constrain issues.

== July 21 to Aug 2 ==

* Solve an issue that .svg image files will be generated in pygtk/canvas after load library: create directory 'pygtk/canvas/.temp' and save all the .svg files into that .temp directory. By modifying {{srcbranch|mike|models/test/canvas/blocktype.py}}

* Piping system library can be loaded now. But still working on equations.

== Discussion notes for August 3 2016 ==

* generate .svg files to ~/.cache/ascend, fix the permission issue by function os.path.expanduser(path).

* Combine Quit (Ctrl+Q) and close button together by assign 'dispensable' argument i.e. Event=None.

* Refresh the workflow for developing piping system model.

== Aug 3 to Aug 9 ==

* 'inout' port is partially implemented by adding similar 'inout' elements with previous 'input' and 'output' elements properly. However error occurs when right click and view 'block properties'.

* Piping system library can solve simple piping problems under fluid mechanics approximation.

== Discussion notes for August 10 ==

* Report current working status.

* General discussion about piping system library.

== Aug 11 to Aug 18 ==

* 'inout' port is fully implemented by checking glade file {{srcbranchdir|mike|pygtk/glade/bp.glade}} and match the variable names. Now, 'inout' port works properly for drawing feedback (can be connected with input/output/inout) and solving.

== Discussion notes for August 19 ==

* Report current working status.

* Schedule next meeting on Monday morning.

== Aug 19 to Aug 22 ==

* Potential connector and flow connector can be detected from library file via syntax 'potential:' and 'flow:', however it only has effects for one layer. E.g. library like this doesn't work:
MODEL electron_stream;
V "potential:" IS_A voltage;
I "flow:" IS_A current;
END electron_stream;

MODEL equipment;
inlet "in:" IS_A electron_stream;
outlet "out:" IS_A electron_stream;
END equipment;

MODEL something REFINES equipment;
...
END something;
But library like this can work, but it doesn't help much for solving problems:
MODEL equipment;
inlet "in:" IS_A electron_stream;
outlet "out:" IS_A electron_stream;
V "potential:" IS_A voltage;
I "flow:" IS_A current;
END equipment;

MODEL something REFINES equipment;
...
END something;
Therefore, further implement is required on this.

== Work after GSOC ==

* Viewing block equations from right click - block properties is enabled, details in {{srcbranchdir|mike|pygtk/canvas/blockproperties.py}}

== Final Review ==

* How to use 'inout' port: (see {{srcbranchdir|mike|models/test/canvas/basic_electronics_model.a4c}} for detail)[[File:canvas_inout.png|thumb|alt='Inout' port is available in canvas|Connecting 'inout' port in canvas]]
** The resistor_basic model has normal 'inlet' and 'outlet' port. But the Ground model only has 'inout' port, which can be connected with any kinds of ports in canvas. The definition of 'inout' port is exactly the same as 'inlet' or 'outlet' ports. Part of the code is shown below:
MODEL Ground;
NOTES
'block' SELF {Ground}
'icon' SELF {ground.png}
'graphic' SELF {5,0-5,5
0,5-10,5
2,7-8,7
4,9-6,9}
'port_inout' SELF {inout:5,0}
END NOTES;
inout "inout:" IS_A electron_stream;
inout.V = 0 {volt};
END Ground;
* Piping system introduction:

* See previous logs for setup environment of my branch.

* Contact me via u5612799@anu.edu.au if you encounter problems / have questions.

* TODO List from me:
** Implement redo function in {{srcbranchdir|mike|pygtk/canvas/undo.py}}
** Improve quit check (quit_confirm) function in {{srcbranchdir|mike|pygtk/canvas/blocklist.py}}
** Improve functions of {{srcbranchdir|mike|models/test/canvas/basic_electronics_model.a4c}}
** Improve functions of {{srcbranchdir|mike|models/test/canvas/piping_system.a4c}}
** Improve potential and flow connectors in various files from {{srcbranchdir|mike|pygtk/canvas}}

== Screenshots ==
<gallery>
File:canvas_GUI.png|Canvas GUI
File:canvas_inout.png|'Inout' port is available in canvas
File:canvas_basic_elec.png|Basic electronic circuit simulation
File:canvas_block_properties.png|Block equation can be viewed from 'block properties'
File:canvas_quit_confirm.png|Warning dialog before quitting canvas
</gallery>

2016-08-30T23:56:56Z

2016-08-28T06:45:13Z

Mike: /* Discussion notes of 12 May 2016 */

[[Category:GSOC2016]]

Name: Tengda Han (Mike)

University: [http://www.anu.edu.au/ ANU]

Email: u5612799@anu.edu.au

Summary: I am doing [[GSOC2016]] for ASCEND. I will do something on Canvas.

* Browse my code here: {{srcbranchdir|mike|}}
* Check out my code using <tt>svn co http://svn.ascend4.org/branches/mike</tt>

== Discussion notes of 12 May 2016 ==

To get the canvas GUI running in the trunk code, I used:

python ~/ascend/trunk/pygtk/canvas/canvas.py

== May 12 to May 22 ==

* Set development environment and play with canvas.

* Find a problem about module 'ascpy' in my branch, which cannot be found in canvas.py.

* But when I run canvas.py of main trunk, module 'ascpy' can be found, but another error is called:'''libascend.so.1: cannot open shared object file: No such file or directory'''

== Discussion notes of 23 May 2016 ==

* cannot find module 'ascpy' is because I need to compile by

scons -j4

* set paths properly before run canvas.py:

export LD_LIBRARY_PATH=~/Desktop/ascend_mike/mike/:$LD_LIBRARY_PATH
export PYTHONPATH=~/Desktop/ascend_mike/mike/models/johnpye/fprops/python:$PYTHONPATH

* find a bug of Adrian's branch, which is, when run the solver, ascend kills the background terminal. Trying different ubuntu system may work.

== May 23 to May 29 ==

* Tested Adrian's branch on ubuntu 16.04 LTS. Previous bug doesn't exist (ascend kills the terminal)

* Try to understand Gaphas and libavoid.

* Link 'libavoid' on ASCEND wiki has 404 error.

* When 'scons' ASCEND in Ubuntu16.04, SWIG error comes. [https://github.com/georgyberdyshev/ascend/commit/6962ef6c2ca36ff6cfff85e98c2daeac82619b82/ sulution here]

== Discussion notes of 30 May 2016 ==

* When try to run canvas.py, should set PYTHONPATH to

ascend_trunk/trunk/model/johnpye/fprops/python

* For Adrian's version

:: canvas.py doesn't work because of

Error: sys.path must be a list of directory names

:: Reason: installed python-gaphas uses gtk2. But we require gtk3 branch of gaphas, Solution:

cd ~/desired directory
git clone https://github.com/amolenaar/gaphas
git checkout gtk3
git pull
sudo python setup.py install

:: However, after canvas.py pops up, ''TypeError: Couldn't find conversion for foreign struct 'cairo.Context''' occurs when click on blank canvas

== May 30 to June 5 ==

* Solved ''TypeError: Couldn't find conversion for foreign struct 'cairo.Context' '' by

sudo apt-get python-gi-cairo

[http://packages.ubuntu.com/trusty/python-gi-cairo This package] is a Python Cairo bindings for the GObject library

* If problems occur when installing gaphas by

sudo apt-get install python-gaphas

[http://www.installion.co.uk/ubuntu/precise/universe/p/python-gaphas/install/index.html/ Check the universe repository] before installation may help

* Undo button works (finishing the work of Adrian), redo haven't been implemented yet.

== Discussion notes of June 6 2016 ==

* Buttons now have labels. By adding ''tb.set_style(Gtk.ToolbarStyle.BOTH)'' after ''tb = Gtk.Toolbar()''

* Delete unnecessary .svg image files in {{srcbranchdir|mike|pygtk/canvas}} only leave defaultblock.svg

* Block icons should be generated by strings, instead of load image. Example: {{srcbranch|mike|models/test/canvas/brayton_fprops_rachel.a4c}}

* Currently svn version is updated to {{changeset|3110}}

* I can improve blocks, firstly to make sure they can be properly solved in canvas.

== June 6 to June 13 ==

* models in {{srcbranch|mike|models/test/canvas/basic_electronics_model.a4c}} have been updated.

* Problems found: every time after using the model in canvas, a '.svg' file of that model will be generated.

== June 13 to June 28 ==

* Working on redo function. Implement redo function in {{srcbranch|mike|pygtk/canvas/undo.py}}

* Fix a bug that rankine_canvas.a4c in {{srcbranch|mike|models/test/canvas/}} cannot run in canvas

* Fix a bug that rankine_stream.a4c in {{srcbranch|mike|models/test/canvas/}} cannot run in canvas

* Fix a bug that rankine_stream_v2.a4c in {{srcbranch|mike|models/test/canvas/}} cannot run in canvas

* Fix a bug that ammonia_synthesis_v2.a4c in {{srcbranch|mike|models/test/canvas/}} cannot run in canvas

* GUI update: Load Library (Ctrl+L) is enabled from menu bar

* GUI update: Correct labels in Block Properties Dialog

== June 29 to July 10 ==

* Fix a bug when adjusting Error/Status Reporter Console

* Rotate(Ctrl+R) and Flip(Ctrl+F) operation is added to menu bar, and keyboard shortcuts of them are enabled.

* Correct current value (I) in running results from {{srcbranch|mike|models/test/canvas/basic_electronics_model.a4c}} library.

* Find a bug: In basic_electronics_model.a4c, when connect 2 ports of T-piece/Branch together and run, Canvas will quit.

* An Error occurs when load canvas files because blocks with same name exist. Solution: 1. add a checker before 'run' or 'save'. 2. avoid reduplicate names when generating blocks.

* Also, a warning 'CompareStatements called with unknown statement' always appears when load files, but seems don't affect the result.

* Add reporter for loading libraries and files.

* Errors including line number can be shown on canvas when loading is unsuccessful.

* Update information in 'Help' Menu

== Discussion notes of July 11 2016 ==

* Automatically generating .svg files when load libraries: save these images into ~/.ascend/tmp

* Preference of units should be improved: modify pygtk/preference.py

* Warning should be displayed when ports not connected

* Models with degree of freedom should not be solved. Warning should be displayed

* In 'Block Properties', equations of blocks should be displayed

== July 11 to July 20 ==

* Correct syntax error in some files

* Improving Block Properties to display equations, by editing relating python files and glade files.

* Warning Dialog added when load new libraries with canvas items existing.

* Warning Dialog added when exiting without saving canvas (still need improve).

== Discussion notes for July 20 2016 ==

* For equation display, some paths may be valuable to check: asclibrary - get module types - library.h - type.h - ismodel(); ascend/compiler - type.descio.h - writedefinition.

* Next Step: Create a library for piping system. Read Mechanics of Fluids. Be careful with flow network & over constrain issues.

== July 21 to Aug 2 ==

* Solve an issue that .svg image files will be generated in pygtk/canvas after load library: create directory 'pygtk/canvas/.temp' and save all the .svg files into that .temp directory. By modifying {{srcbranch|mike|models/test/canvas/blocktype.py}}

* Piping system library can be loaded now. But still working on equations.

== Discussion notes for August 3 2016 ==

* generate .svg files to ~/.cache/ascend, fix the permission issue by function os.path.expanduser(path).

* Combine Quit (Ctrl+Q) and close button together by assign 'dispensable' argument i.e. Event=None.

* Refresh the workflow for developing piping system model.

== Aug 3 to Aug 9 ==

* 'inout' port is partially implemented by adding similar 'inout' elements with previous 'input' and 'output' elements properly. However error occurs when right click and view 'block properties'.

* Piping system library can solve simple piping problems under fluid mechanics approximation.

== Discussion notes for August 10 ==

*

== Aug 11 to Aug 18 ==

* 'inout' port is fully implemented by checking glade file {{srcbranchdir|mike|pygtk/glade/bp.glade}} and match the variable names. Now, 'inout' port works properly for drawing feedback (can be connected with input/output/inout) and solving.

== Discussion notes for August 19 ==

* Report current working status.

* Schedule next meeting on Monday morning.

== Aug 19 to Aug 22 ==

* Potential connector and flow connector can be detected from library file via syntax 'potential:' and 'flow:', however it only has effects for one layer. E.g. library like this doesn't work:
MODEL electron_stream;
V "potential:" IS_A voltage;
I "flow:" IS_A current;
END electron_stream;

MODEL equipment;
inlet "in:" IS_A electron_stream;
outlet "out:" IS_A electron_stream;
END equipment;

MODEL something REFINES equipment;
...
END something;
But library like this can work, but it doesn't help much for solving problems:
MODEL equipment;
inlet "in:" IS_A electron_stream;
outlet "out:" IS_A electron_stream;
V "potential:" IS_A voltage;
I "flow:" IS_A current;
END equipment;

MODEL something REFINES equipment;
...
END something;
Therefore, further implement is required on this.

== Work after GSOC ==

* Viewing block equations from right click - block properties is enabled, details in {{srcbranchdir|mike|pygtk/canvas/blockproperties.py}}

== Final Review ==

* See previous logs for setup environment of my branch.

* Contact me via u5612799@anu.edu.au if you encounter problems / have questions.

* TODO List from me:
** Implement redo function in {{srcbranchdir|mike|pygtk/canvas/undo.py}}
** Improve quit check (quit_confirm) function in {{srcbranchdir|mike|pygtk/canvas/blocklist.py}}
** Improve functions of {{srcbranchdir|mike|models/test/canvas/basic_electronics_model.a4c}}
** Improve functions of {{srcbranchdir|mike|models/test/canvas/piping_system.a4c}}
** Improve potential and flow connectors in various files from {{srcbranchdir|mike|pygtk/canvas}}