On 4 March 2011 09:28, Martin Albrecht <martinralbre...@googlemail.com> wrote: > On Friday 04 March 2011, David Kirkby wrote:
>> Perhaps a very different approach is needed. One thing I feel Sage >> lacks is engineering applications. How about basing the applications >> upon building engineering applications on the top of maths software, >> rather than adding more maths? > > Hi David, if you take a look at last years application you'll see that it > wasn't that particularly heavy on the mathematics. > > http://wiki.sagemath.org/gsoc10 > > Cheers, > Martin I found the Wiki, but not the application. I take your point it was not too mathematica, but did look a bit "unfocused" to me, though perhaps offering a wide range of possible projects is useful. Some listed there were clearly not practical in the time frame of 3-month. Ports to AIX or HP-UX would take a LOT more than 3 months. However, making a number of packages play well on those platforms would be quite doable - some would only take a day or less I think. More emphasis could have been put on a C99 library and its use to a multitude of other projects - not just Sage. The following ideas reflect my own bias, but something that might be better is: * Focus just on engineering applications for Sage. Make every project related to engineering, as this is one area where MATLAB does very well, and Mathematica a bit less so. MATLAB has a number of toolboxes focused on engineering. http://www.mathworks.com/products/ Projects which might be suitable would be. * Electonic circuit analysis using symoblic maths like the "Nodal" package for Mathematica does, and totally avoid numerical simulation software, as there are plenty of very good tools for this - Spice being the most well known of them all. (I think William had a student who expressed some interst in this). * Antenna design. The equations for the typical Yagi-Uda antenna are easy to solve, so getting something to compute the properties of a Yagi Uda antenna would not be difficult. What is much more difficult, is to optimise the element spacing and lengths to get an optimal design. That's a global optimisation problem. I tried something like this years ago using a genetic algorithm, though the GA approach was not the best I found. * Add GPIB support for Linux only - probably the only platform where this is doable with totally free software. FreeBSD would be possible if the port was complete. Solaris and OS X would probably need to use a commerical driver for the GPIB card. As I remarked the other day, the real issue to get commerical developers to use Sage for instrument control is having drivers for their instruments. But if the basic GPIB driver was implemented, then a couple of commands could be written in Sage to basically send and receive data. Drivers for specific instruments would essentially require the user to write the code based on their manual for the instrument. Getting a cheap instrument to test the basic code on is very easy. * Digital filter design tool. MATLAB has this too in a toolbox. Basic filter would be quite easy to implement. More sophisticated adaptive filters would be possible for the brightest students. As the filters get more sophisticed, so does the maths behind them. * Analogue filter design - some comments apply as for digital filters. * Implement any of the MATLAB toolboxes where a suitable mentor could be found. In cases like an aerospace toobox, I doubt there's a suitable mentor available in the Sage community. * Solving thermal problems such as heat transfer through walls, subject to the boundary conditions specified. I see quite an intersting request from someone recently who wanted to find the optimal dimensions for a heat spreader for a heatsink. Basially one has ** Transistor dumping heat in a small area - the dimension of its package. ** Large alluminium (Al) heat since, but alluminium is not a great conductor of heat. This would be cooled by a fan, so convection is the dominate mode of heat transfer and conduction and radiation could be ignored. ** A copper (Cu) "heat spreader" of dimenssion x y z which sits between the transistor and heat sink . Assuming the only method of heat transfer from the heat spreader is conduction, which would be true to a high degree of accuracy, then there must be an optimal thickness for this. I suspect heat transfer would increase if you make the width and height bigger, but due to the cost of copper, one would have to trade them off. At what point does it become pointless to make x and y bigger? Given a specific volume of copper (and so cost), what are the optimal dimensions? Make it too thick and the heat will never reach the convection cooled heatsink. Make it too thin and the heat will be concentraed in a small area of the heatsink and not spread across all its size. * I don't know of any way to add a finite element front end onto Sage, but if there was, that would open up a huge range of possibilies. There are some finite element software based on Python - see for example http://pfem.sourceforge.net/ That might be a bit challenging in 3 months, and would be a bit of an all-or-nothing project. If the student was quite poor, you would end up with nothing useful at all. Anyway, that's my thought. Concentrate on one focused area (engineering applications), but offer as many ideas as its practical. Most of these engineering applications basically require one implements algorithms based on maths which has already been solved. Sage should have the maths capabilites - the challenge is appliying that maths to practical engineering problems. FWIW, I know Google have someone dedicated to hiring just engineers, as he contacted me, so I suspect engineering applications might be quite appealing to them. That sort of approach might appear more structed than a huge scattering of very diverse projects. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
