Idea #4:

Extending SfePy to encompass FEVA - Finite Element Vibration Analysis [1] 

[1] http://books.google.co.in/books/about/Introduction_to_Finite_Element_Vibration.html?id=N71ACcE-dXwC&redir_esc=y 



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.

r.

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:
>>
>> Thanks!
>>
>> SfePy is now listed among teams at [1]. The dates and deadlines are at the
>> bottom of [2].
>>
>> r.
>>
>> [1] http://wiki.python.org/moin/SummerOfCode/2013
>> [2] https://www.google-melange.com/gsoc/events/google/gsoc2013
>>
>> 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 [1].
>>>>
>>>> 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.
>>>>
>>>> [1] http://sfepy.org/doc-devel/development.html