You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
(29) |
May
(23) |
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(18) |
Oct
(2) |
Nov
(32) |
Dec
(32) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(2) |
Feb
(5) |
Mar
(7) |
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
2004 |
Jan
(2) |
Feb
(7) |
Mar
|
Apr
(1) |
May
|
Jun
(4) |
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Geraint P. B. <ge...@us...> - 2003-11-25 15:20:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wrote: | | has anyone come across the error message in the title before? It is a | Reduce error, but I'm not sure what is causing it. Reduce works fine | normally. | Problem solved. Evidently some recent update to the system upset Reduce. I've applied the latest patches.red and rebuilt the Reduce psl image and it all seems to be behaving properly now. - -- Geraint. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iEYEARECAAYFAj/Dcy4ACgkQcXV3N50QmNPGpwCfb8gAlXoemSDlJa08y7j183oc YeAAnirdnZ4tSTn2NN8nn/scv0f+M7LK =Ur79 -----END PGP SIGNATURE----- |
From: Geraint P. B. <ge...@us...> - 2003-11-25 11:59:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, has anyone come across the error message in the title before? It is a Reduce error, but I'm not sure what is causing it. Reduce works fine normally. gbevan@gbevan-pc:~/rc $ mtt rc odeso view MTT (Model Transformation Tools) version 5.0 ($Date: 2003/09/23 20:53:49 $) This is free software with ABSOLUTELY NO WARRANTY. Type `mtt warranty' for details. Copying .octaverc Copying useful-functions.hh Creating rc_cmp.txt Creating rc_sub.sh ... Creating rc_subs.r Creating rc_rdae.r INFORMATION: An MTT transformation has generated the following messages ***** Segmentation Violation ***** Fatal error: Error not within ErrorSet Creating rc_dae.r INFORMATION: An MTT transformation has generated the following messages ***** Segmentation Violation ***** Fatal error: Error not within ErrorSet Creating rc_ae_write.r Creating rc_cse_write.r Creating rc_csex_write.r Creating rc_cseo_write.r Creating rc_ae.r Creating rc_cse.r Creating rc_csex.r Creating rc_cseo.r INFORMATION: An MTT transformation has generated the following messages ***** Segmentation Violation ***** Fatal error: Error not within ErrorSet Creating rc_smxa.m in matrix form INFORMATION: An MTT transformation has generated the following messages ***** Segmentation Violation ***** Fatal error: Error not within ErrorSet make: *** [rc_smxa.m] Error 1 Exiting MTT with error 2 Exiting MTT with error 1 gbevan@gbevan-pc:~/rc $ - -- Geraint. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iEYEARECAAYFAj/DQ/EACgkQcXV3N50QmNPqDQCcCsoIWSWpMmP8rRjtJs1cZ/FW V2MAnR06tA6AAwjHR+Opv3jI57JaC+UD =nOZm -----END PGP SIGNATURE----- |
From: Geraint P. B. <ge...@us...> - 2003-09-24 10:23:07
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've uploaded .deb, .rpm and .tgz versions to sourceforge. The .deb works for me, but I can't test the rpm. Would it perhaps be worthwhile to include the manual as part of the file release? I know it is located on mtt.sf.net (which seems to have turned yellow!) but it may also be useful for anyone downloading the .tgz (which doesn't have the manual pre-built). Geraint. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iEYEARECAAYFAj9xcIMACgkQcXV3N50QmNNqFQCcCd7un5mj+mu0550/jTFoIZ1N bdYAnR7SAUJACATdBLGiQDfmbAYzu0Gb =6Njy -----END PGP SIGNATURE----- |
From: Peter G. <mt...@ga...> - 2003-09-23 16:21:42
|
Hi Geraint, good - -oct and -cc now working. Could you do an rpm and a deb for me to put on mtt.sf.net? Many thanks, P. PS I assume that libkpathsea-dev, libreadline-dev, libncurses-dev, blas-dev, lapack-dev, fftw-dev are in the dependencies. I had to load them myself to get -cc working! Peter Gawthrop mt...@ga... http://mtt.sf.net |
From: Peter G. <mt...@ga...> - 2003-08-19 21:44:53
|
Hi everyone, I'm trying to move towards a release of MTT 5.0. mtt now successfully compiles all examples (mtt sys rep pdf) except for the Control and the ABG trees. I intend to leave it at that in the interests of a rapid release. I have updated mtt.sf.net (have a look); in particular a new manual and new examples. Unfortunately, latex2html has let mtt down in variouas places, but the pdf looks good using acroread 5. I have commited all changes to CVS (I hope). I would like your help as follows: Geraint: Please make sure all the examples run when mtt is aliased to mtt -cc and mtt -oct. Please do a deb and pass to Donald. Donald: Please try to install on a "fresh" machine and compile all the examples: $MTT_DOC/mtt_make_examples. It will create ~/JUNK/examples to do this. Thanks, Peter. Peter Gawthrop mt...@ga... http://mtt.sf.net |
From: Peter G. <p.g...@en...> - 2003-06-23 14:05:48
|
Hi Roger, as we discussed, you need a number of gnu tools (www.gnu.org) installed under Solaris for mtt to work. In particular, you will need the following (generated from mtt --versions) Doing the GNU components Trying gawk ... is OK and has version GNU Awk 3.1.2. Trying basename ... is OK and has version basename (GNU coreutils) 5.0. Trying cat ... is OK and has version cat (coreutils) 5.0. Trying cp ... is OK and has version cp (coreutils) 5.0. Trying dirname ... is OK and has version dirname (GNU coreutils) 5.0. Trying gcc ... is OK and has version 2.95.4. Trying grep ... is OK and has version grep (GNU grep) 2.5.1. Trying head ... is OK and has version head (coreutils) 5.0. Trying make ... is OK and has version GNU Make 3.80. Trying octave ... is OK and has version GNU Octave, version 2.1.36 (i386-pc-linux-gnu).. Trying sed ... is OK and has version GNU sed version 4.0.5. Trying tail ... is OK and has version tail (coreutils) 5.0. Trying tr ... is OK and has version tr (coreutils) 5.0. In addition you will need: Doing the non-GNU components Trying xfig ... is OK and has version Xfig 3.2 patchlevel 3d (Protocol 3.2) Trying fig2dev ... is OK and has version fig2dev Version 3.2 Patchlevel 3d All compilers from Gnu Compiler Collection 2.95.2 Libraries from version 5.0. All of these work with sparc-sun-solaris 2.7. You will also need LaTeX. If your system people have problems, please contact Yassmine Mather <ya...@en...>. When you have got that far, I will give you the latest MTT. Peter. -------------------------------------------------------------------- | Prof. Peter J Gawthrop | Tel: +44 141 330 4960/2528 | | Centre for Systems and Control & | Fax: +44 141 330 4343 | | Dept. of Mechanical Engineering | Room: James Watt 653 | | University of Glasgow | Email: P.G...@en... | | GLASGOW G12 8QQ, Scotland, UK | URL: www.mech.gla.ac.uk/~peterg | -------------------------------------------------------------------- |
From: Geraint <ge...@ge...> - 2003-04-17 21:53:06
|
Peter Gawthrop <mt...@ga...> writes: > Hi Geraint, > > I have today added files to the CVS tree for an updated version of the > sese rep. > > The new features are: > 1. Aliasing > 2. In-line resolving of CRs using gino -- just handles one-port lin at > the moment. > > I have tested it on > rc > rc2 > MaplesonModelP > MacroMicro > > At the moment, it does not handle systems with loops or > bicausality. Also, I still need to write the _seqn.m files for some > components -- _eqn.m files are no good as they write out all of the > component's equations in one place. > > As the _sese.r file is already sorted; it could be used directely > (with some minor processing) in c or m form. Could you have a go at > this? It would be very interesting to compare complexity of the code > for large systems generated via sese and via differential-algebraic > equation rep; I am hoping that this will me a much better way of > generating code. Anyway, let me know how you get on. > > I don't intend doing more on this myself for a while; but will handle > any bugs that you turn up (if you can't fix them yourself). > > Best wishes, > > Peter > > Peter Gawthrop > > mt...@ga... > http://mtt.sf.net > Peter, I've made a couple of minor changes; it is now possible to get a (correct) plot using "mtt -sort rc odeso view" (without having Reduce installed!). I haven't modified the C/C++ code generation - I'll wait until the m format is working properly before changing that, as there does seem to be a bit of a problem with the equation sorting. Although rc works fine, the equations are not always correctly sorted for other systems. For instance, in rc2, the variable rc2__rc_1_3_flow appears on the RHS before the LHS. Any ideas? Geraint. |
From: <ge...@ge...> - 2003-04-08 10:16:28
|
Peter, below is an example script which demonstrates the reduce latex interface (rlfi). The output is dependent on both the rlfi switches and the normal reduce settings. This script contains the best combination of switches that I've found so far. Unfortunately there doesn't appear to be any way to get it to break lines intelligently. Geraint. #! /bin/sh reduce <<EOF load rlfi$ off rounded; on allfac; on div; on rat; on ratpri; off nosplit; out "rlfi.tex"; on latex; on lasimp; defid rho,name=rho; a := Cd * 8 * rho / ( pi * d^2 )$ b := 300 * rho + 7 * rho * sqrt(Pm - Pd)$ c := Pd - 0.2 * (Pm - Pd)$ Q_i := ( -b + sqrt(b^2 - 4*a*c) ) / (2 * a); Q_i := ( -b - sqrt(b^2 - 4*a*c) ) / (2 * a); off latex; shut "rlfi.tex"; ;end; EOF latex rlfi.tex xdvi rlfi.dvi |
From: Peter G. <mt...@ga...> - 2003-03-25 17:45:02
|
Hi Geraint, I have today added files to the CVS tree for an updated version of the sese rep. The new features are: 1. Aliasing 2. In-line resolving of CRs using gino -- just handles one-port lin at the moment. I have tested it on rc rc2 MaplesonModelP MacroMicro At the moment, it does not handle systems with loops or bicausality. Also, I still need to write the _seqn.m files for some components -- _eqn.m files are no good as they write out all of the component's equations in one place. As the _sese.r file is already sorted; it could be used directely (with some minor processing) in c or m form. Could you have a go at this? It would be very interesting to compare complexity of the code for large systems generated via sese and via differential-algebraic equation rep; I am hoping that this will me a much better way of generating code. Anyway, let me know how you get on. I don't intend doing more on this myself for a while; but will handle any bugs that you turn up (if you can't fix them yourself). Best wishes, Peter Peter Gawthrop mt...@ga... http://mtt.sf.net From: Peter Gawthrop <mt...@ga...> Subject: First version of sese available. Date: Thu, 13 Mar 2003 15:55:10 +0000 (GMT) > Hi Geraint, > > I have just uploaded the first version of the sese.r rep. It took more > effort than I expected; but I think the basic principles are > established: it recursively generates the sorted ese.r file for > heirachical systems. > > Try: > mtt rc sese r > > and test it with: > cp rc_sese.r rc_ese.r > mtt rc dae view > > Also works with rc2 (new test example) > > TBD. > 1. Test on more systems. > 2. Include aliasing > 3. Include in-line resolving of CRs using gino > > Will try and do these over the next few weeks. > > Best wishes, > > P. > > Peter Gawthrop > > mt...@ga... > http://mtt.sf.net |
From: Peter G. <mt...@ga...> - 2003-03-24 09:16:08
|
The variable names generated by mtt have been of the form Name(BondNumber,BondCausality) where BondCausality is 1,2 or 3. I have just changed varname.m so that the names are now: Name_BondNumber_BondCausality where BondCausality is effort,flow or state. In principle, this should have no effect. This is, in fact, the original form, which was changed to avoid reduce running out of variable name space. Please look out for potential problems arising from this and let me know. Peter. Peter Gawthrop mt...@ga... http://mtt.sf.net |
From: Geraint <ge...@ge...> - 2003-03-13 21:24:30
|
Peter, the sorted equations look good. I particularly like the extra-informative comments that are included in the code - they should help simplify the task of debugging a lot. I think that TBD#4 might be parameter passing. rc works fine; rc2 seems to stumble with the passed parameters when built using sese.r (it works fine using the normal ese.r route): rc2_lbl.txt: ... ## Component type RC rc_1 lin c_1;r_1 rc_2 lin c_2;r_2 ... rc2_dae.r: (using sese.r) ... MTTdX(1,1) := (c*e_s - mttx1)/(c*r);$ MTTdX(2,1) := (mttx1 - mttx2)/(c*r);$ ... [note "c" and "r" instead of "c_1", "c_2", "r_1" and "r_2"] Geraint. |
From: Peter G. <mt...@ga...> - 2003-03-13 15:55:36
|
Hi Geraint, I have just uploaded the first version of the sese.r rep. It took more effort than I expected; but I think the basic principles are established: it recursively generates the sorted ese.r file for heirachical systems. Try: mtt rc sese r and test it with: cp rc_sese.r rc_ese.r mtt rc dae view Also works with rc2 (new test example) TBD. 1. Test on more systems. 2. Include aliasing 3. Include in-line resolving of CRs using gino Will try and do these over the next few weeks. Best wishes, P. Peter Gawthrop mt...@ga... http://mtt.sf.net |
From: Peter G. <mt...@ga...> - 2003-03-13 15:16:02
|
Hi Geraint&Dominic, __ is now used to delimit subsystems. This changes names in the state and input files as well as function names and internal variable names. The initial version of sorted equations (sese.r) should be there by Friday pm. P. Peter Gawthrop mt...@ga... http://mtt.sf.net |
From: Dominic D. <dom...@ba...> - 2003-03-04 09:32:54
|
Sorry everyone, we have a non-standard address format. Here is the second= attempt. D ---------------------- Forwarded by Dominic Diston/Technical/MAA/BAe on= 04/03/2003=20 09:26 --------------------------- To: mt...@ga... cc: ge...@ge...,= mtt...@li...=20 Paper Mail:=09 Subject: Re: [Fwd: Naming of subsystems] =20 Hi Peter, My vote is to allow single underscores in component names and to use double= =20 underscores in the hierarchical decomposition. Banning double underscores from component names would be no great pain. Thus, your example would become aa__bb__cc and,if I want to be verbose, I= could=20 write: top_level_model__subsystem_model__component_model. From our experience here, underscores are vital in breaking up name strings= because=20 system names tend to be compound; also, double underscores would make the struc.txt much easier to read (as= opposed=20 to the current "_" or the now superseded "_1_") as well as removing the current ambiguity between name breaks and hierarchy. Hope you're keeping well. Dominic RFC-822=3Dg...@ge... on 28/02/2003 11:25:09 Please respond to RFC-822= =3Dg...@ge...@INTERNET@wtgw To: dom...@ba...@INTERNET@wtgw cc: =20 Paper Mail:=09 Subject: [Fwd: Naming of subsystems] *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 >=20 > From: Peter Gawthrop <mt...@ga...> > Date: Fri 28/Feb/2003 10:25 GMT > To: ge...@ge... > CC: mtt...@li... > Subject: Naming of subsystems >=20 > Hi Geraint, >=20 > I need to be clear about whether we disallow _ in subsystem names.=20 >=20 > If so, mtt can assume that aa_bb_cc is component cc within subsystem > bb within system aa. This means, for example that struc files can be=20 unambiguously > interpreted and, in general, it makes many parts of mtt simpler.=20 >=20 > Is it OK if we keep this restriction on names?=20 > =20 > P. >=20 > Peter Gawthrop >=20 > mt...@ga... > http://mtt.sf.net >=20 >=20 __________________________________________________________________________ Freeserve AnyTime - Go online whenever you want for just =A36.99 a month= for your first 3 months, that's HALF PRICE! And then it's just =A313.99 a month after that. For more information visit http://www.freeserve.com/time/ or call free on=20 0800 970 8890 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** |
From: Geraint <ge...@ge...> - 2003-03-01 01:16:46
|
Peter Gawthrop <mt...@ga...> writes: > Hi Geraint, > > maybe the answer is to use __ within names to delimit subsystems, that > is allow _ but dissallow __ in names. What do you think? > Sounds good to me. Geraint. |
From: Peter G. <mt...@ga...> - 2003-02-28 15:31:02
|
Hi Geraint, maybe the answer is to use __ within names to delimit subsystems, that is allow _ but dissallow __ in names. What do you think? P. Peter Gawthrop mt...@ga... http://mtt.sf.net |
From: Peter G. <mt...@ga...> - 2003-02-28 10:25:15
|
Hi Geraint, I need to be clear about whether we disallow _ in subsystem names. If so, mtt can assume that aa_bb_cc is component cc within subsystem bb within system aa. This means, for example that struc files can be unambiguously interpreted and, in general, it makes many parts of mtt simpler. Is it OK if we keep this restriction on names? P. Peter Gawthrop mt...@ga... http://mtt.sf.net |
From: Peter G. <mt...@ga...> - 2003-02-25 15:09:33
|
Hi Geraint, As you suggested, I've put a release on mtt.sf.net. I will announce on the octave list as a reply to a recent request. P. Peter Gawthrop mt...@ga... http://mtt.sf.net |
From: Geraint <ge...@ge...> - 2003-02-19 22:18:10
|
Peter Gawthrop <mt...@ga...> writes: > Hi Geraint, > > I've been silent since xmas as I've been working on 2 things: > > 1. Generation of ordered equations from the CBG file. > ================================================= > > This is still broken, but the basic idea of recusively generating > simple equations in computational order (using the causal strokes) > is there. I plan to resolve CRS on a per-equation basis at this > level using ginsh. > > Should have a working version in a few weeks. > > 2. Real-time code generation. > ========================= > > For a long time, I have wanted to be able to run controllers > represented by bond graphs in real time. So far I am using RTlinux > 3.2 with comedi for a/d d/a stuff. I plan to use RTLab > (www.rtlab.org) as a basis for this; MTT will generate both a > kernel module for the real-time stuff together with a QT-based GUI > as plugins to the basic RTLab interface. > > I have sucessfully installed RTLab, comedi and RTlinux on my laptop > as well as linux box. So I now have a software oscilloscope running > at 1kHz. > > A longer term project, comments/sugestions welcome at this stage. > > P. > > Peter Gawthrop > > mt...@ga... > http://mtt.sf.net Hi Peter, the ordered equations will definitely be a very useful improvement; I found a slight problem with the global optimisation recently - for one particularly long and complicated expression, a series of assignments were produced in which some variables were used uninitialised. I have reverted the mapping of the default optimisation (-opt) to -optl. -optg is probably still fine for medium-large models, but care should be taken to ensure that -Wuninitialized is used with it. I did download RTLinux a while ago, but I never quite got around to downloading and patching the kernels that were required to go with it (IIRC, there were only patches for 2 kernel versions, neither of which were particularly good choices for my system). I see that there is now a LiveCD on the rtlab site. I will have to give this a try (not that I actually have any data acquisitian hardware to do anything useful with). For my part, I haven't quite got around to finishing the ibg2abg stuff needed to get xfig and dia working via a common method as much as possible. I will have to do this soon - I don't seem to have much time to spend on it recently! I also mentioned gino on the octave-help list today - there have been a few questions about combining Octave with symbolic algebra lately and it does seem like the perfect solution. Perhaps it would be a good idea to put a tarball on the MTT release page to make it easier for people to grab copies. BTW, did you make it to ICBGM this year? Did it go well? Geraint. |
From: Peter G. <mt...@ga...> - 2003-02-13 17:01:24
|
Hi Geraint, I've been silent since xmas as I've been working on 2 things: 1. Generation of ordered equations from the CBG file. ================================================= This is still broken, but the basic idea of recusively generating simple equations in computational order (using the causal strokes) is there. I plan to resolve CRS on a per-equation basis at this level using ginsh. Should have a working version in a few weeks. 2. Real-time code generation. ========================= For a long time, I have wanted to be able to run controllers represented by bond graphs in real time. So far I am using RTlinux 3.2 with comedi for a/d d/a stuff. I plan to use RTLab (www.rtlab.org) as a basis for this; MTT will generate both a kernel module for the real-time stuff together with a QT-based GUI as plugins to the basic RTLab interface. I have sucessfully installed RTLab, comedi and RTlinux on my laptop as well as linux box. So I now have a software oscilloscope running at 1kHz. A longer term project, comments/sugestions welcome at this stage. P. Peter Gawthrop mt...@ga... http://mtt.sf.net |
From: Geraint <ge...@ge...> - 2003-01-06 21:08:22
|
David Hoover <dav...@ep...> writes: > Parsing labels will be easy--we just need to agree on what to do with > the labels once they are parsed. Didn't you > once mention the possibility of having the connections in the abg.m > file instead of the rbg.m file? Doesn't it make > sense for abg.m to have all GUI independent stuff, and for rbg.m to > have FIG-dependent stuff? > > Should we try that out? > > Dave. > Hi Dave, I hope that all is well with your new arrival. I'll hazard a guess that this hasn't been your most relaxing holiday season ever. I think that what is needed is an intermediate step between rbg.m and abg.m. rbg.m contains raw data in the form of bond/component co-ordinates etc. whereas abg.m contains a fully interpreted acausal bond graph with all the vector bonds, port names and aliases expanded. Something like the attached LeakyCylinder_ibg.m would be the most sensible way of doing things; this basically consists of the raw connectivity of rbg.m with the information of what objects are connected to each other but without the interpretation of what the bond graph means. I will have a crack at creating an rbg2ibg and ibg2abg transformation based on the current rbg2abg. If it works okay for fig files, it should be straightforward to adapt dia2abg.pl to write an ibg.m file. This would then allow a common means of expanding port names and vector bonds. /Geraint. |
From: Peter G. <mt...@ga...> - 2003-01-06 11:08:22
|
From: Geraint <ge...@ge...> Subject: Re: [Mtt-developers] GiNaC, maxima and optimisation Date: 23 Dec 2002 18:26:50 +0000 > Peter Gawthrop <mt...@ga...> writes: > > > Hi Geraint, > > > > I'm doing crs a (slightly) different way at the moment. The idea is > > that really all we want is pattern matching, not functions. So a CR > > is now a list. > > > > I attach rc_rdae.g, rc_dae.g and rc_cr.g to explain what I > > mean. Comments please! > > > > I will modify gino install as you suggest. > > > > Best wishes, > > > > Peter > > > > Peter Gawthrop > > > > mt...@ga... > > http://mtt.sf.net > > #SUMMARY lin linear constitutive relationship > > #DESCRIPTION Parameter 1 defines input causality relating to parameter 2 > > #DESCRIPTION value is effort, flow or state > > #DESCRIPTION Parameter 2 is the gain corresponding to the causality of > > #DESCRIPTION parameter 1. > > #DESCRIPTION Supported components: > > > > #DESCRIPTION single port components: R,C,I > > #Linear Constitutive Relationship for single port components: R,C,I. > > # e = Gain*f (if gain_causality = flow) > > # f = Gain*e (if gain_causality = effort) > > > > ## In causality and gain causality the same > > MTT_all = subs(MTT_all, {{lin,$3,$1,$5,1,$2,$3,1}}, {$2*$1}); > > > > ## In causality and gain causality different > > MTT_all = subs(MTT_all, {{lin,$3,$1,$5,1,$2,$4,1}}, {$2/$1}); > > > > #DESCRIPTION two port component: TF > > ##Linear Constitutive Relationship for TF > > ##Unicausal form > > > > ## In causality and gain causality the same > > MTT_all = subs(MTT_all, {{lin,$3,$1,$5,1,$2,$3,2}}, {$2*$1}); > > MTT_all = subs(MTT_all, {{lin,$3,$1,$5,2,$2,$3,1}}, {$2*$1}); > > > > ## In causality and gain causality different > > MTT_all = subs(MTT_all, {{lin,$3,$1,$5,1,$2,$4,2}}, {$2/$1}); > > MTT_all = subs(MTT_all, {{lin,$3,$1,$5,2,$2,$4,1}}, {$2/$1}); > > > > MTTdX_1= (-c^(-1)*MTTx_1+MTTu_1)*r^(-1); > > MTTy_1= c^(-1)*MTTx_1; > > MTTdX = { > > {lin,flow,r,flow,1,MTTu_1-{lin,effort,c,effort,1,MTTx_1,state,1},effort,1} > > }; > > MTTy = { > > {lin,effort,c,effort,1,MTTx_1,state,1} > > }; > > Hi Peter, > > that looks like it should work okay. The numeric wildcards are a little cryptic compared to Reduce's free variables, but I'm sure we can live with that. > > If CRs are going to be re-written, perhaps now would be a good time to consider refining slightly the format of equations output by MTT. You mentioned long ago that you weren't entirely happy with the means of differentiating between different types of components in lin.cr. If we include the component name along with the CR (e.g. {AF,lin,flow,1,...} {TF,lin,flow,1,...} it would be easy enough to write a few wrappers to map {C,lin,...}, {I,lin,...} {R,lin,...}. The main advantage of this would be the ability to specify a consistent format for all MTT CRs (mitigating the cryptic syntax somewhat). > > I notice that it is not possible to add non-list items to lists: > > > eq_1 = {func,a,b,c,d} + 3; > add::eval(): sum of non-commutative objects has non-zero numeric term > > > eq_1 = {func,a,b,c,d} + {3}; > {3}+{func,a,b,c,d} > > so it will be necessary to wrap everything within lists. However, I don't think that this will cause any problems - it may actually make it easier to parse expressions correctly for LaTeX. > > You also mentioned sorting of equations in a previous message - have you looked at that yet? > > Geraint. > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mtt-developers mailing list > Mtt...@li... > https://lists.sourceforge.net/lists/listinfo/mtt-developers Hi Geraint, it is quite easy to add the component name in the cr; the hard part is rewriting the cr files. However I will do that tommorrow (and redo r/lin.cr) as long as you don't mind broken cr's for a while. Sorting is a more major problem (its the heirachical structure that is the issue), but I plan to start on it in the next 2 weeks. I will keep in close touch with you on this and will write an experimental cbg2sese (sorted ese) which will eventually replace cbg2ese. Best wishes, P. Peter Gawthrop mt...@ga... http://mtt.sf.net |
From: David H. <dav...@ep...> - 2002-12-24 14:36:14
|
Geraint wrote: >Well, my modem is still smoking but that did the trick - it works! I will play! > > Sorry Geraint--I forgot that you were using a modem to connect. Here's a much smaller file you can update your bondgraph stuff with to have working labels. Parsing labels will be easy--we just need to agree on what to do with the labels once they are parsed. Didn't you once mention the possibility of having the connections in the abg.m file instead of the rbg.m file? Doesn't it make sense for abg.m to have all GUI independent stuff, and for rbg.m to have FIG-dependent stuff? Should we try that out? Dave. These files may be used and copied according to the GNU General Public License. See http://www.gnu.org/ for details. |
From: Geraint <ge...@ge...> - 2002-12-23 18:36:33
|
Peter Gawthrop <mt...@ga...> writes: > Hi Geraint, > > I'm doing crs a (slightly) different way at the moment. The idea is > that really all we want is pattern matching, not functions. So a CR > is now a list. > > I attach rc_rdae.g, rc_dae.g and rc_cr.g to explain what I > mean. Comments please! > > I will modify gino install as you suggest. > > Best wishes, > > Peter > > Peter Gawthrop > > mt...@ga... > http://mtt.sf.net > #SUMMARY lin linear constitutive relationship > #DESCRIPTION Parameter 1 defines input causality relating to parameter 2 > #DESCRIPTION value is effort, flow or state > #DESCRIPTION Parameter 2 is the gain corresponding to the causality of > #DESCRIPTION parameter 1. > #DESCRIPTION Supported components: > > #DESCRIPTION single port components: R,C,I > #Linear Constitutive Relationship for single port components: R,C,I. > # e = Gain*f (if gain_causality = flow) > # f = Gain*e (if gain_causality = effort) > > ## In causality and gain causality the same > MTT_all = subs(MTT_all, {{lin,$3,$1,$5,1,$2,$3,1}}, {$2*$1}); > > ## In causality and gain causality different > MTT_all = subs(MTT_all, {{lin,$3,$1,$5,1,$2,$4,1}}, {$2/$1}); > > #DESCRIPTION two port component: TF > ##Linear Constitutive Relationship for TF > ##Unicausal form > > ## In causality and gain causality the same > MTT_all = subs(MTT_all, {{lin,$3,$1,$5,1,$2,$3,2}}, {$2*$1}); > MTT_all = subs(MTT_all, {{lin,$3,$1,$5,2,$2,$3,1}}, {$2*$1}); > > ## In causality and gain causality different > MTT_all = subs(MTT_all, {{lin,$3,$1,$5,1,$2,$4,2}}, {$2/$1}); > MTT_all = subs(MTT_all, {{lin,$3,$1,$5,2,$2,$4,1}}, {$2/$1}); > > MTTdX_1= (-c^(-1)*MTTx_1+MTTu_1)*r^(-1); > MTTy_1= c^(-1)*MTTx_1; > MTTdX = { > {lin,flow,r,flow,1,MTTu_1-{lin,effort,c,effort,1,MTTx_1,state,1},effort,1} > }; > MTTy = { > {lin,effort,c,effort,1,MTTx_1,state,1} > }; Hi Peter, that looks like it should work okay. The numeric wildcards are a little cryptic compared to Reduce's free variables, but I'm sure we can live with that. If CRs are going to be re-written, perhaps now would be a good time to consider refining slightly the format of equations output by MTT. You mentioned long ago that you weren't entirely happy with the means of differentiating between different types of components in lin.cr. If we include the component name along with the CR (e.g. {AF,lin,flow,1,...} {TF,lin,flow,1,...} it would be easy enough to write a few wrappers to map {C,lin,...}, {I,lin,...} {R,lin,...}. The main advantage of this would be the ability to specify a consistent format for all MTT CRs (mitigating the cryptic syntax somewhat). I notice that it is not possible to add non-list items to lists: > eq_1 = {func,a,b,c,d} + 3; add::eval(): sum of non-commutative objects has non-zero numeric term > eq_1 = {func,a,b,c,d} + {3}; {3}+{func,a,b,c,d} so it will be necessary to wrap everything within lists. However, I don't think that this will cause any problems - it may actually make it easier to parse expressions correctly for LaTeX. You also mentioned sorting of equations in a previous message - have you looked at that yet? Geraint. |
From: Peter G. <mt...@ga...> - 2002-12-23 11:11:52
|
From: Geraint <ge...@ge...> Subject: Re: [Mtt-developers] GiNaC, maxima and optimisation Date: 20 Dec 2002 17:13:53 +0000 > Peter Gawthrop <mt...@ga...> writes: > > > Hi Geraint, > > > > I've been having a closer look at both maxima and ginac (via the ginsh > > shell). I believe that for the simple end of mtt, ginsh is much > > cleaner and straight forward than maxima (or reduce). I have > > investigated the basics of ese --> rdae --> differential-algebraic > > equation and it looks fine - though of course the crs need rewriting. > > > > At the back end, print_latex and print_csrc (ie c source code) have > > just arrived in ginsh though I have not tried them yet. > > > > I still need to get ginac going in octave - I plan to move to unstable > > debian to do this! But that will tacke the medium-level stuff using > > for loops. > > > > I am still unclear about optimisation. FWIW, I have a feeling that we > > are going about things the wrong way. I think that I should rewrite > > cbg2ese to: > > > > a) write out ordered equations > > b) avoid writing duplicate equations > > > > The early (prolog) version of mtt did exactly this; but I was seduced > > by the fact that reduce gobbled up equations in any order. The problem > > with the current approach is that reduce actually make experessions > > more complicated in an uncontrolled way; which then have to be > > optimises back to simplicity. This is to some extent conjecture at the > > moment, but I think a rewrite of cbg2ese is worth trying. > > > > To summarise, I plan a few experimental ginsh-based transformations > > over the next few weeks; and (having discussed further with you) put > > the new cbg2ese on the wish list. > > > > Best wishes, > > > > Peter. > > > > Peter Gawthrop > > > > mt...@ga... > > http://mtt.sf.net > > > > > > Hi Peter, > > I hadn't realised that MTT started out as prolog. You could well be right about the optimisation. As long as each expression is not the length of a short novel, I think gcc can optimise code perfectly well. It is only the complexity of monster 30k expressions produced by Reduce that requires the use of a separate optimiser. > > If expressions are kept simple, then GiNaC looks like it should be up to the task. I'm not so certain about ginsh though - from the man page: "There is no way to define your own functions other than linking ginsh against a library that defines symbolic GiNaC functions". Recompiling ginsh to add a new CR could be a bit inconvenient. > > Assuming that you haven't already found a way round this potential problem, it may be better just to use GiNaC directly - the syntax doesn't look too bad. As it is C++, this would also offer the tremendous benefit of allowing conditional statements within CRs (something that would eliminate a lot of hoops that usually have to be jumped through) and static variables to ensure that look-up tables aren't evaluated multiple times per time step. > > By the way, I like gino - very nice. You should definitely let the developers of GiNaC know about it, there are a few places in the documentation where they lament the lack of loops and conditionals in ginsh. The octave community would also doubtless be very interested. Two minor comments: 1) it may be better to amend the Makefile slightly to install in .../site/m/gino which would make it easier to remove/upgrade 2) the licencing terms are a little confusing (public domain+BSD+GPL?) > > As for upgrading debian, I've seen a few comments recently reporting that unstable debian is very unstable at the moment, so it may be better to play it slightly safer with the testing distribution. > > Geraint. Hi Geraint, I'm doing crs a (slightly) different way at the moment. The idea is that really all we want is pattern matching, not functions. So a CR is now a list. I attach rc_rdae.g, rc_dae.g and rc_cr.g to explain what I mean. Comments please! I will modify gino install as you suggest. Best wishes, Peter Peter Gawthrop mt...@ga... http://mtt.sf.net |