Jump to: navigation, search

My name is Liang He. I am now a student of Graduate University of Chinese Academy of Sciences at Beijing, China. My mayor is computer science and techs. I have not get in touch with open source project before and hope this is a good start with ascend. I will be very glad to contribute what I could to make ASCEND better. :)

The following is an interesting model I wrote according to a story I heard several days before.

REQUIRE "atoms.a4l";
MODEL FallDownFromHigh;
        people_mass              IS_A        mass;
        building_height          IS_A        distance;
        time_falldown            IS_A        time;
        v                        IS_A        speed;
        time_stop                IS_A        time;
        f                        IS_A        force;
        (* equations comes here *)
        BuildingHeight:        building_height = 0.5 *1{EARTH_G} * time_falldown ^ 2;
        Speed: v =  1{EARTH_G} * time_falldown;
        ImpulseConservation: f * time_stop = people_mass * v;
END FallDownFromHigh;

Screen shot that I managed to compile the ASCEND successfully and get it worked on my system:

Error creating thumbnail: File missing
ASCEND up and running on my system

Screen shot show the function of recent files list(bug 533):


GSoC Goals:

  • CYTHON is researched and decide how to rewrite.
  • Rewrite is done as required (standard: flexible and easy to extend).
  • GUI codes still works well as before.


  • Before April 25th: More research on SWIG and CYTHON. Estimate the work load in each way and the possible benefits.
  • Before the end of May:
    • Discussed with mentor about my research result and decide which way to go.
    • Make a detail design on rewriting work (maybe include test case design).
    • Start to do rewriting work.
  • June to July 15th (Mid-term evaluation):
    • Done with rewriting work.
    • Part of GUI codes rewritten should have been done.
  • July 15th to August 15th (Final evaluation):
    • All goals achieved.
    • Bug fix.


  • until 5.22
    • Decided to stick on SWIG to do rewrite work. We both agreed that the target is to make the python bindings smaller and faster by removing C++ codes from swig interface file.
    • Make sure that it is the %template definition that leads the code bloated. Still try to find a good way to remove these definitions.
  • 5.22-5.29
    • Try some ideas on SWIG files to replace the %template definitions but we could still have those convenient APIs provided by python bindings. Reading the python mannual, mostly those chapters about PyObejcts and refcounts etc, to see whether we could do that by using SWIG's %typemap feature. Most of those ideas are proved to be impossible to implement or to complex. Finally, I find we could remove those %template by simply using %typemap. Before we define a %template, we use typemap to make sure the PyObject pointer is directly passed through but not converted or processed by SWIG internal codes. Then we could operate on these PyObject pointer which holds the variable that we pass in at python layer. Soon I tested this idea by write a simple testing code. Good new is the result is what I want. Bad news is there may be something I didn't notice the test code crashed after I exited the python command line. I doubted that these may be lead by the ref-count issue of PyObject type.
  • 5.29-6.6
    • A vacation home for personal issues. Sorry to JP that I didn't let him know in time.
  • 6.6-6.11
    • I have researched the python's refcount issue for a while and tested the code I proposed many times. I found that it is not always leading to a segmentation fault. So, after I modified the code with considering the ref-count issue, I could not be sure the problem has been solved. Then, I tried another method by wrapping manually before using SWIG (That is to wrap using C++ manually firstly and then let SWIG do the work left). In this way, there is no need to add %typemap. The only problem is to implement proper interfaces in the container proxy class. In an example, I only implemented a few of the vector's APIs. I think this may be a better method to remove those %template definitions. I am sure there will be no segmentation fault.
  • 6.11-6.17
    • When I searched through the pygtk codes, it seems there is no source code file referencing those types defined by %template. So I just tried to comment out all the %template definitions and compiled to find out that the is just half the size of that before. So the conclusion is %template do leads to code bloat. The first step to rewrite these definitions is surely right. The second step may be to rewrite the "instanc" related interface codes which is already be tagged as needing to remove in future. Right now , I am writing the map and set containers which could hold pyobject correctly in order to be used in python layer. If these are all done, I think they could replace those %template definitions completely.
  • 6.17-6.20
    • Now I am trying to figure out the difference between ASCXX_Set and the std::set. I found ASCXX_Set is a wrapper of of gl_list_t which is based in ascend/general/list.c. Then I know this list type is coded very long time ago. It could store and fetch elements in a list in constant time ( O(1) ). And the list type stores pointers of datas by converting them to 'void *' type. So the list can store any kind of data. While searching in the ascend/general directory, I see this type is widely used internally. But the python types (such as ASCXX_Set) defined by %template is actually not used in pygtk GUI layer. I could imagine that these types could be prepared to be used in future. So I think this ASCXX_Set may could be replace with the standard std::set. Then we could wrap types in a more uniform way.
  • 6.20-6.26
    • This time, I have completely removed %template definitions and replaced them with four new types which could provide almost the same APIs as those types defined by %template. The container.h wraps three standard container of C++, such as vector, set, map. They could be used in python layer as those types defined by %template. The python internal object's ref-count issue has already been considered in the implementation. So I think it would be safe to use now. As for the type ASCXX_Set, it is extended in interface file and defines two new types(SetInt, SetString). Now I removed these two new types definitions defined by %template. Two new C++ wrapper classes are implemented to replace these two types.
    • But I still have concerns on the ASCXX_Set type. In the interface file, the ASCXX_Set's constructor is defined as private which means the python layer couldn't instantiate ASCXX_Set. So I think it is impossible to use SetInt and SetString in python layer in the original bindings. And now, after rewriting these two types, the same issue remains. So I am thinking to find another way to make these two types useful.
  • post mid term evaluation
    • Discussing task for the next stage with mentor. Reading codes of ascends compiler related codes. Making proposal with respect to our discussion result.
    • Coding on compiler system, test my ideas in my proposal.

Proposal for slvreq related syntax extension

  • Our current syntax for solver:
    • SOLVER sname
    • OPTION pname value
    • SOLVE
  • Possible syntax for integrator:
    • INTEGRATOR eginename
    • INTEGRATE FROM start TO end STEPS n
    • OPTION pname value
    • SOLVE
  • How to unify the two kinds of syntax?
    • Extend the current SOLVER syntax, makes it could deal with the case of integrator. That is to let the compiler knows whether it is a solver or an integrator and then the compiler could call different APIs to do the right thing.
    • SOLVER sname ISINTEGRATOR. The ISINTEGRATOR token indicates that we are assigning an integrator engine which will be used to solve problem. In this way, we could let the compiler know what it is dealing with as soon as it meets a SOLVER token. Then it could decide what kind of statement creation APIs should be called.
    • When the ISINTEGRATOR token is assigned, the compiler calls statement creation API to create corresponding statement which will indicate this is an integrator. When the SOLVE command trigs the execution session, this statement will then get integrator’s engine selection API called to choose the specific integrator engine.
    • This statement is used to assigning independent variable’s settings. When in execution period, this statement is evaluated to call integrator’s API to create its sample list which will be used to integrate the problem.
    • Here we don’t specify which variable is independent variable. As what the current GUI based integrator does, the independent variable could be found by calling integrator_find_indep_var.
  • Unified new syntax:
    • SOLVER slv_name [ISINTEGRATOR]
    • [INTEGRATE FROM v_start TO v_end STEPS n]
    • OPTION slv_parameter_name value
    • SOLVE
  • By using this new syntax, we could still use the old syntax to deal with those problems don’t use integrator. Almost in the same way, we could indicate the compiler that we want to use integrator to solve the problem.