Some results and feedback

Aug 29, 2014 at 12:46 PM
Edited Aug 30, 2014 at 1:40 AM
Just wanted to let you know that I set up a "real world" steel tower problem by modifying some existing truss analysis software I had been working on to use BFE.NET

The results were spot on and the performance was quite good.

Image

Image

I will be anxious to see it when the P-Delta analysis is added.

One thing you might want to consider for future implementation is tension-only beams (to allow modelling cables and chains).

Thanks again for making this available to the open source community!
Coordinator
Aug 30, 2014 at 1:12 PM
Hi.
Thanks for information.
Please feel free to use this library in your application, also please check out the license context of this library (available here as LGPL) to see legally what are you permitted to do with the library and its source code.

Did you compare the result from this application with another application? if yes, was you faced with any numeric error in this output regarding the other application?

Regards
Aug 31, 2014 at 2:14 AM
My app has an existing engine developed in-house. I like to keep abreast of available libraries.

Thanks for making the license LGPL, I find LGPL to strike the best balance, All of my open source code is LGPL also.

I found the results to line up well for forces and reactions at the nodes. I have yet to perform a more detailed analysis but I will keep you informed.

Thanks again.
Coordinator
Aug 31, 2014 at 5:32 AM
Thanks for information.
I'm not so familiar with elements like tension beam, also for next several months I think i'll have to focus on analyzing and developing another version of this library which is parallel version of BriefFiniteElement.NET (parallel in all time consuming parts like matrix decomposition etc.) as my thesis.. Till then maybe I have no enough time to focus on adding new features to this library.

Regards
Sep 2, 2014 at 12:02 PM
Interesting.

I must advise caution.. I have made versions of my solver that attempted to use parallel execution (specifically the parallel foreach facility that is part of .NET) to improve performance. The problem is that there is an overhead associated with spinning up each parallel task thread and (at least in the case of my solver) the performance penalty involved in executing the threads and synchronizing the results eclipsed gains achieved by parallel execution.

I WAS able to achieve a performance improvement by applying parallelism on a per load case basis. In my case I needed to solve the problem with the loads applied in a number of different ways (I was modelling the application of wind load on a structure with the wind at differing angles relative to the structure). I did achieve a performance improvement by having each wind load case solved in a separate thread since in that scenario the thread setup penalty was less than the total load case solution process load.

I would encourage you to read the following article before diving too deeply into your project. It should be a simple matter to write some parallel process test cases to determine whether your thesis that parallel execution of the (somewhat shallow) decompositions will in fact yield a performance improvement given the .NET parallelism model.

http://msdn.microsoft.com/en-us/library/dd997392(v=vs.110).aspx

I am concerned that you may find that the parallel execution architecture of .NET (as opposed to some of the more specialized parallel architectures available) may not give you the results you are seeking.

Good luck
Coordinator
Sep 3, 2014 at 1:21 PM
Hi,
Thanks for information.
I did used the Parallel.For in .net (inside built in TPL library) in a very simple dense matrix multiplication and i get noticeable improvement (i don't know why I didn't really expect so! :) )
Making the obvious sections of the library to run in parallel is as easy as to replace normal foreach loop with Parallel.Foreach. But making the direct equation solving system (like cholesky decomposition) to run in parallel is a nightmare! it should be coded from ground up or in other words, its not possible to use Parallel.For or Parallel.Foreach on the current situation, in addition, many other things like graph partitioning should be considered and re implemented in C# (this is nested nightmare for me!).
There are two families of solvers for using in applications/libraries like this library and thanks to a guy named Christian Woltering, this library has both of these types of solvers. On large and medium problems, the solving of equation system is most time consuming task (specially the cholesky). For example in my case, in analyzing a 15x15x15 grid described in Performance Page for a single load case, more than 98% of time is spent on solving eq. system with cholesky method. It means best performance improvement can be achieved by overclocking other parts is 2%. and in other hand a slight improvement in cholesky decomposition can have effect more than this.
Anyways thanks for the information and the link about pitfalls in parallelism in .NET, i did already seen it and it was quite helpful. Would be happy to hear more from you on paralleling in .net.
Also profiler tools like jetbrains dotTRACE and built in profiler in VS Ult. are somehow simple and very useful for seeing which part of application is taking most of time.

Regards