On Wednesday, 3 April 2013 18:38:27 UTC+5:30, Robert Cimrman wrote:
On 04/03/2013 02:47 PM, Ankit Mahato wrote:
> 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
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...
Cheers,
r.
[w] https://github.com/sfepy/sfepy/wiki
>
>
>
> 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
>>
>>
>