This is the path I have come up with for my GSoC idea implementation: Convection-Diffusion (Steady) Convection-Diffusion (Unsteady) Convection-Diffusion coupled with phase change Meso-Scale Dendritic growth (with convection,diffusion,phase change)
Kindly lend your view.
On Wednesday, 3 April 2013 18:58:02 UTC+5:30, Ankit Mahato wrote: >
yes robert i got hold of the book yesterday and it covers a wide range. I will edit the wiki with ideas.
On Wednesday, 3 April 2013 18:38:27 UTC+5:30, Robert Cimrman wrote: >
On 04/03/2013 02:47 PM, Ankit Mahato wrote:
Extending SfePy to encompass FEVA - Finite Element Vibration Analysis 
You mean adding modal analysis capabilities for solids? The book has quite a broad range...
I have set up a wiki page [w] for this list of ideas, as looking them up in this thread might become difficult. I have also added you to our contributors team at github, hoping it's enough to get you wiki edit rights. Let me know if it is not so - we have not use the wiki for quite some time...
On Thursday, 21 March 2013 15:38:09 UTC+5:30, Robert Cimrman wrote:
Of course, if there is anybody else willing to try getting paid by Google for work on SfePy, do not hesitate and let us know.
On 03/20/2013 11:19 AM, Ankit Mahato wrote:
Awesome. :) :)
I am currently working on something. Will be posting here soon :)
On Wednesday, March 20, 2013 2:11:04 PM UTC+5:30, Robert Cimrman wrote:
SfePy is now listed among teams at . The dates and deadlines are at the bottom of .
On 03/19/2013 12:17 PM, Ankit Mahato wrote:
> Hi everyone, > > Here is the full text version of the Ideas as Robert requested: > > #1 Parallelization > > I went through the mailing list wherein it has been mentioned that SfePy > can support multicore via numpy/scipy multicore support, but compute > cluster support is not available which requires knowledge of MPI. So we can > add computing cluster support where jobs need to communicate with each > other and exploit the high performance computing in order to make it > scalable. In Python it can be done using mpi4py module. > > > > #2 Pre-processing and Post-Processing combined with SfePy > > One of the reason why people use proprietary software is their ease to use. > We can build complete simulation platform with powerful frontend for > pre-processing to analysis to post-processing. This will include the script > support wherein people can write scripts to post process the data on the > platform itself. Also it will be made modular so as to make it extensible. > We can look into integrating it with CAD packages like PythonCAD or built > our own pre-processor or postprocessor using powerful GUI toolkit to > provide the complete simulation solution. > > #3 incorporating coupled equations for phase changing materials > > Incorporating Phase changing material simulation which has never been done > in any simulation software package before. Since it is my research area I > will develop its model based on various research paper and my own research > and encorporate it into SfePy. > Regards, > Ankit Mahato > > On Tuesday, 19 March 2013 16:32:22 UTC+5:30, Robert Cimrman wrote: >> >> Hi, >> >> we are trying to sign up under the PSF umbrella for this year's Google >> Summer >> of Code because of an e-mail from Ankit Mahato, who expressed interest to >> help >> developing SfePy as his GSoC project this summer. >> >> So let us discuss possible project ideas here. I will post results of the >> discussion to . >> >> Ankit's ideas are (my summary): >> >> #1 parallelization - cluster support using mpi4py >> #2 pre- and post-processing GUI frontend >> #3 incorporating phase changing materials (his research area) >> >> Ankit, could you post full text your ideas into this thread? The pdf you >> sent >> me does not allow selecting text. >> >> My comments: >> >> For me, #1 is something that I was planning to do "soon" anyway as I am >> going >> to need it for my research work - a help would come really handy, but we >> will >> have to think carefully about the implementation. I think I prefer having >> a >> parallel layer above the current serial FEM, so that the current code can >> stay >> as it is, unaware that it runs in parallel. I am not sure yet how >> difficult it >> is going to be, but it won't be trivial. >> >> #2 would be nice, but IMHO it is not so important as having a solid and >> reasonably fast FEM core. >> >> #3 would IMHO be the most useful for Ankit, and a nice addition to >> modelling >> capabilities of SfePy. >> >> Other possible topics can be found in our issues list ("enhancement" >> label). >> >> IMHO it would be good to prospective student(s) to try tackling some of >> the >> issues listed below to get acquainted with SfePy code before the GSoC >> starts: >> >> #196 Document properly term evaluation modes and postprocessing/probing. >> #195 describe how to add Neumann BC in a diffusion example and tutorial >> (tutorial part done by Alec) >> #167 improve gallery page >> #164 Python 3 compatibility >> #154 automatic testing of terms >> #140 test schroedinger.py >> #133 Provide examples for SfePy Terms >> >> Implementing the other enhancements would be, of course, also very useful, >> but >> those IMHO too difficult for someone trying to learn the code. They are >> certainly quite difficult for me, as they are not done yet =:) (shell >> elements!) >> >> Cheers, >> r. >> >>  http://sfepy.org/doc-devel/development.html