Hi Arash I found that I didn't need to set ANONFORCE to 1 in order to run the bintoken functionality. I have written a very simple test case and added it to our test suite. If you have got CUnit up and running then you can do
cd ~/ascend svn up scons -j2 test test/test compiler_bintok This will load a very simple model and give you some output that shows the bintoken functions are being correctly called. I believe you are correct and derivatives are not being exported as bintokens. Clearly we will want to look into that. At bintoken.c:628, there is a comment "here we could also write gradient code based on i, indexU". I can imagine that writing the gradient function will be a bit tricky, because whereas in 'native' function evaluation in ASCEND we calculate gradient by automatic differentiation, which is fairly efficient, for bintoken evaluation of gradients we have to export code that does the same differentiation job. Not trivial! We either have to work out a symbolic derivative and write out code for that, or else write code that does the same maths as the automatic differentiation, some little piece of stack-based code. Second derivatives, as required for optimisation solvers, are another problem again. So, looks like this will be a barrier to easily progressing with your parallel solver proposal. One easier but dependency-adding option that we could possibly consider would be to use ADOL-C or CppAd to generate the autodiff code from the exported C code, for addition to the compilable C code, in a form that hopefully could be swallowed by CUDA. Cheers JP Arash Sadrieh wrote: > Hi John, > > > Sorry this change was missing: > > In "ascend/ascend/compiler/instantiate.c:line 12176" have been changed > to "#define ANONFORCE 1" > > Thanks > Arash > > -----Original Message----- > From: John Pye [mailto:[email protected]] > Sent: Friday, 11 February 2011 7:51 PM > To: Arash Sadrieh > Subject: Re: FW: ASCEND - GPU based solvers. > > Hi Arash > > That's great! I'll try to follow your suggestions and make same changes. > > For bug fixes, the best thing is a "svn diff" attached to an email (if > you can fix the bug) else a bug report (ascendbugs.cheme.cmu.edu) (if > you can't fix it). But if you can't be bothered, an email is better than > > nothing, of course! > > Cheers > JP > > On 11/02/11 7:48 PM, Arash Sadrieh wrote: > >> Thanks John, >> >> It seems the "BINTOKEN" problem was resolved :D !!! >> >> Followings have been changed: >> >> 1) In "/ascend/Bintokens/Makefile", ASC_INCDIR and ASC_LIBDIR are >> changed to correct location that the compiler can see "prolog.h", >> "enum_instance.h" and "platform.h". >> 2) "/ascend/Bintokens/btprolog.h:line 61" have been changed to >> > "#include > >> <platform.h>" >> 3) "/ascend/compiler/bintoken:line 402" have been changed to >> "CLINE("#include<btprolog.h>");" >> >> They are also couple of other minor bugs in the documentation, website >> and readme files .... >> >> I just create a simple spreadsheet for them and just wondering how >> should I report/fix them, >> >> Regards, >> Arash >> >> P/S: I have build a virtual development PC for ASCEND based UBUNTU >> > 9.10, > >> EMACS+GDB and couple of other useful tools if you think it is useful I >> can upload it somewhere. >> >> >> >> >> >> >> -----Original Message----- >> From: John Pye [mailto:[email protected]] >> Sent: Friday, 11 February 2011 3:38 PM >> To: Arash Sadrieh >> Subject: Re: FW: ASCEND - GPU based solvers. >> >> Hi Arash >> >> Sounds awesome. We made a lot of changes to the way we handle >> > 'external > >> libraries' in ASCEND, with the addition of 'importhandler' and >> > 'ospath' > >> modules that were written by me. With the exception of the *unloading* >> of dlopened files, I think those things are basically working OK now, >> but it's possible you might find a bug. DLL/SO unloading is perhaps >> something that needs to be fixed if we start using the bintoken stuff, >> or else we'll end up with heaps of different loaded DLL/SOs floating >> around in memory, potentially. >> >> For the bintoken stuff, I imagine you could access the 'AscDynaLoad' >> stuff directly, although the ospath stuff is probably going to be >> > useful > >> in providing multi-platform support. >> >> If the compilation is failing, it's probably to do with missing '-I' >> flags, missing header files, or simply not locating 'gcc' correctly. >> Just guessing. >> >> Ben Allan might have some ideas about ways to get support for >> > developing > >> your project further. Perhaps we should talk to him about that once >> you've made a some promising progress... >> >> Cheers >> JP >> >> Arash Sadrieh wrote: >> >>> Hi John, >>> >>> I trust that you are well, >>> >>> During last week I have been busy with some papers and thankfully, >>> >> they >> >>> have been finished yesterday and that means I am back to the ASCNED. >>> >>> About my current status, today, I just completed the configuration of >>> EMACS + GDB and have started the debugging ... >>> >>> As you said, the problem is not that serious and I think I have >>> > almost > >>> found the root: >>> >>> "asc_bintoken.c" file is not compiled properly therefore, >>> "ascDynamLoad.c: Asc_DynamicLoad" function fails when it tries to >>> > load > >>> "\tmp\asc_bintoken.os" library, I hope that this bug fixed at the end >>> >> of >> >>> today, >>> >>> Thank you so much for explaining my research to Prof Brent and I am >>> >> glad >> >>> that he shows interest. I think although the first results are >>> encouraging, however, the project can be extended in many different >>> aspects. Thus, I am searching for any opportunities to develop the >>> project further ... >>> >>> Have a nice weekend , >>> >>> Regards, >>> Arash >>> >>> -----Original Message----- >>> From: John Pye [mailto:[email protected]] >>> Sent: Friday, 11 February 2011 2:24 PM >>> To: Arash Sadrieh >>> Cc: Ben Allan; [email protected] >>> Subject: Re: FW: ASCEND - GPU based solvers. >>> >>> Hi Arash >>> >>> How's it going? Have you been working on your CUDA solver by any >>> >> chance. >> >>> I would be very keen to find out how it's going. >>> >>> For what it's worth, I went and spoke to Prof Richard Brent this >>> > week, > >>> he is a senior guy in the CS department here at ANU. He is about to >>> teach a course on parallel programming, and is working on adding new >>> stuff on GPU/GPGPU stuff to the course, as it's not in his textbook. >>> > I > >>> passed your name to him, as he seemed to be interested in the whole >>> solvers-for-GPUs thing. >>> >>> Are you still stuck on the bintokens stuff? I will see if I can take >>> > a > >>> look at it next week, if so. As I think I said, I believe the bug to >>> >> be >> >>> fairly superficial. >>> >>> Anyway, please do let me know how things go, and in the meantime, >>> > have > >> a >> >>> nice weekend! >>> >>> Cheers >>> JP >>> >>> Arash Sadrieh wrote: >>> >>> >>>> Hi John, Ben, >>>> >>>> Thank you so much for all the information and support, >>>> >>>> I think, now it is a time for me to take serious look at ASCEND code >>>> >>>> >>> and plan the feature developments. The first step in my view is >>> > fixing > >>> the broken code generator for "bintokens". >>> >>> >>>> I will inform you about how things are progressing... >>>> >>>> >>>> Ben - >>>> >>>> Could you please kindly explain the "EXPOSURE to GPU and solver >>>> > code" > >>> more accurately for me? >>> >>> >>>> I am asking this due to the fact that we had published couple of >>>> >>>> >>> papers (they are still in review process so we can withdraw). >>> Furthermore, we are going to publish everything as a thesis. >>> >> Therefore, >> >>> I was wondering what do you think about the whole publishing issues >>> considering fact that we are JUST integrating our implementation with >>> the ACM through the interface they provided? >>> >>> >>>> I appreciate it. >>>> >>>> Best regards, >>>> Arash >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Ben Allan [mailto:[email protected]] >>>> Sent: Friday, 4 February 2011 3:01 AM >>>> To: Arash Sadrieh >>>> Cc: John Pye >>>> Subject: Re: FW: ASCEND - GPU based solvers. >>>> >>>> Hi Arash, John, >>>> >>>> Unfortunately, your previous work with ACM means that for legal >>>> >>>> >>> purposes >>> >>> >>>> you most likely have been exposed to GPU and solver code which >>>> > ascend > >>> must >>> >>> >>>> stay *very* far away from. A completely new approach to exploiting >>>> >>>> >>> parallelism >>> >>> >>>> is possible (and probably better for your resume if your aim is to >>>> build experience >>>> with performance improvement in many ways). Even if you are the best >>>> intentioned person in >>>> the world, we can never say the same for the ASPEN legal team. >>>> >>>> Intel threaded building blocks and OpenMP are both potential ways to >>>> >>>> >>> benefit >>> >>> >>>> the majority of the ascend community running on commodity machines. >>>> >>>> The current maximum performance (for most chemical/thermal process >>>> >>>> >>> models >>> >>> >>>> written entirely in ascend language) is obtained by inspecting the >>>> >>>> >>> model (which >>> >>> >>>> might include 100000+ equation instances) for the subset of unique >>>> equation forms -- >>>> typically this subset is only 100-500 -- and then >>>> >> generating/compiling >> >>>> the C code for >>>> that form and dynamically linking it back to the interactive >>>> environment for evaluation >>>> with any of our solvers. >>>> >>>> A different code generation approach could be taken (if absolute >>>> maximum performance >>>> on a single model configuration is the target. The minimum set of >>>> equations is still needed >>>> (and available from the system), but you might also take into >>>> > account > >>>> block partitioning >>>> and generate the solver code on the fly -- this would allow blocked >>>> residuals and gradients >>>> to be evaluated in parallel. The actual parallel evaluation could be >>>> implemented any >>>> number of ways (hardware specific or not) once the blocking and >>>> reduction are completed. >>>> >>>> The 'hardest' version of the above is making the current ascend >>>> equation evaluator >>>> thread safe and then running that existing code under any >>>> >>>> >>> multithreading scheme. >>> >>> >>>> Ben >>>> >>>> On Wed, Feb 2, 2011 at 7:57 PM, Arash Sadrieh >>>> >>>> >>> <[email protected]> wrote: >>> >>> >>>> >>>>> Hello Ben, >>>>> >>>>> After looking at the information about "Parallelize solvers" in the >>>>> >>>>> >>> website, I can see that there are a number of similarities with what >>> > I > >>> have done previously in my PhD: In my research, I have used GPU based >>> solvers with ACM and received considerable performance >>> improvement(~20x). >>> >>> >>>>> Based on this, I think that GPU-based parallel solvers can be used >>>>> >> in >> >>> ASCEND in order to improve the performance. Thus, I was hoping you >>> >> could >> >>> kindly give me some advice about the current status of parallel >>> >> solvers >> >>> before I proceed with the project. >>> >>> >>>>> I appreciate your time and look forward to your response. >>>>> >>>>> Best regards, >>>>> Arash >>>>> >>>>> -----Original Message----- >>>>> From: John Pye [mailto:[email protected]] >>>>> Sent: Thursday, 3 February 2011 10:32 AM >>>>> To: Arash Sadrieh >>>>> Cc: Ben Allan >>>>> Subject: Re: ASCEND - GPU based solvers. >>>>> >>>>> Hi Arash >>>>> >>>>> Thanks very much for contacting me. Yes, participation in GSOC is >>>>> >>>>> >>> open >>> >>> >>>>> to you (providing you are currently enrolled as a student at the >>>>> >> time >> >>>>> that you apply -- check this for yourself). And, we expect to again >>>>> participate this year, providing that Google continues to include >>>>> > us > >>> in >>> >>> >>>>> their programme. >>>>> >>>>> Implementing GPU-based or otherwise parallel solvers for ASCEND >>>>> > have > >>>>> been something we would like to see progress on for quite some >>>>> > time. > >>> Ben >>> >>> >>>>> Allan, CCed, in particular, is very interested in this area, and >>>>> >>>>> >>> knows >>> >>> >>>>> more about it that I do. >>>>> >>>>> ASCEND is an unfunded project at this stage; progress occurs when >>>>> >> one >> >>> or >>> >>> >>>>> other of us gets fired up with some enthusiasm and writes some >>>>> > code, > >>> or >>> >>> >>>>> else when a student comes along and wants to do a project with us, >>>>> including GSOC but also a few students at ANU, IIT-B, UAH and >>>>> >>>>> >>> elsewhere. >>> >>> >>>>> As such, our roadmap is something that is very well mapped out. We >>>>> >>>>> >>> have >>> >>> >>>>> a list of 'nice-to-haves', many of which are driven by my personal >>>>> interest area of solar thermal energy system modelling. You may >>>>> > have > >>>>> seen our current activities listed: >>>>> >>>>> http://ascendwiki.cheme.cmu.edu/Development_activities >>>>> >>>>> Broadly, the active areas can be identified as >>>>> >>>>> * improving support for modelling of dynamic systems (improved >>>>> syntax, boundary-switching solvers, etc.) >>>>> * improved support for energy systems modelling (developing >>>>> > model > >>>>> components for turbines, heat exchangers, etc, and learning >>>>> > how > >>> to >>> >>> >>>>> make robust models that are usable by non-experts) >>>>> * improved support for accurate thermodynamics calculations >>>>> >>>>> >>> (FPROPS, >>> >>> >>>>> and we would like to go further with chemical mixtures and >>>>> reactions too) >>>>> * improvements to the GUI, better support for plotting, >>>>> > parameter > >>>>> studies, optimisation, etc. >>>>> * cleaning up the codebase to make things easier for new >>>>> contributors (reducing use of global variables, cleaning out >>>>> >> the >> >>>>> C++ code and migrating to C + Python only, possibly >>>>> >> implementing >> >>> a >>> >>> >>>>> new compiler with more modern parser tools) >>>>> >>>>> >>>>> I think that if you have already implemented a GPU-based solver for >>>>> Aspen then it should be relatively straightforward for you to >>>>> >>>>> >>> implement >>> >>> >>>>> something similar (or BETTER) for ASCEND, and we would of course be >>>>> >>>>> >>> very >>> >>> >>>>> excited at that prospect. >>>>> >>>>> The #1 most important thing to tell you is that we have a huge >>>>> >> amount >> >>> of >>> >>> >>>>> interest from potential GSOC students and this year we have decided >>>>> >>>>> >>> that >>> >>> >>>>> priority will go to those students who have ALREADY made useful >>>>> contributions to our code. We have found that such students always >>>>> produce high-quality work during GSOC. So I'd encourage you get >>>>> >>>>> >>> download >>> >>> >>>>> the code, compile it, and start thinking about what you can do to >>>>> >> get >> >>>>> started. We're both here to help! >>>>> >>>>> Cheers >>>>> JP >>>>> >>>>> Arash Sadrieh wrote: >>>>> >>>>> >>>>> >>>>>> Dear John, >>>>>> >>>>>> >>>>>> >>>>>> I hope this email find you well. >>>>>> >>>>>> >>>>>> >>>>>> My name is Arash Sadrieh; currently I am completing a PhD degree >>>>>> >> at >> >>>>>> Murdoch University in Perth, Western Australia. In a nutshell, my >>>>>> research involves improving the computational performance of >>>>>> >> process >> >>>>>> simulation software tools . More specifically, I have applied the >>>>>> graphics card as a massively parallel co-processor and received >>>>>> considerable performance improvements over traditional CPU >>>>>> implementations. I have used Aspen Custom Modeller environment as >>>>>> >> my >> >>>>>> implementation framework (GPU-based integrator and optimiser are >>>>>> integrated with the ACM). >>>>>> >>>>>> >>>>>> >>>>>> I have been monitoring your ASCEND project since 2008 and have >>>>>> >>>>>> >>> noticed >>> >>> >>>>>> the great improvements in both functionality and usability. >>>>>> >>>>>> As I am currently finishing the writing process of my thesis, I >>>>>> >> will >> >>>>>> have plenty of time in up-coming months while the thesis is being >>>>>> reviewed. Therefore, I would like to contribute to ASCEND project. >>>>>> >>>>>> >>>>>> >>>>>> Based on this and my experience with numerical methods, I was >>>>>> >> hoping >> >>>>>> you could kindly give me some advice about following questions: >>>>>> >>>>>> >>>>>> >>>>>> 1) What is the project roadmap? >>>>>> >>>>>> 2) How can I contribute to the priorities defined on the >>>>>> >>>>>> >>> website? >>> >>> >>>>>> 3) I have couple of ideas - specifically about GPU based >>>>>> >>>>>> >>> solvers, >>> >>> >>>>>> what should I do in order to develop these ideas? >>>>>> >>>>>> 4) Can I be involved, in the next Google summer of code? >>>>>> >>>>>> >>>>>> >>>>>> I appreciate your time and look forward to your response. >>>>>> >>>>>> >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Arash Sadrieh >>>>>> >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Dr John Pye >>>>> Dept of Engineering >>>>> Australian National University >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> > > -- Dr John Pye Dept of Engineering Australian National University ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Ascend-sim-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ascend-sim-users
