This project has moved and is read-only. For the latest updates, please go here.


Aug 1, 2014 at 10:46 AM
Edited Aug 4, 2014 at 7:34 PM
I'm not familiar with structural analysis using FEM, but I guess your matrices are always spd? You should consider using iterative solvers like cg and make the whole solving process more configurable to the user. I've used your benchmark application testing cholesky vs. cg:
        Grid Size:      15x15x15
        Element Count:  9450
        Node Count:     3375
        DoF Count:      20250
On my machine, cholesky takes ~20sec, while cg converges in ~2sec.

I've added the Solver namespace, the only classes that changed are Model and StaticLinearAnalysisResult. I haven't cared to make this accessible to the user. To change the solver type, open StaticLinearAnalysisResult and find the lines
//ISolver<double> solver = new PCG(new SSOR());
ISolver<double> solver = new DirectSolver();
Aug 1, 2014 at 5:35 PM
Yes, as I've seen in some notes, the matrices should be SPD always.
Thanks for source codes of iterative solvers, I'll include them into project asap, but first i have to look at the code to find out the big picture.
I believe iterative solvers option is useful for this project.
Would you like to join this project?

Aug 1, 2014 at 5:38 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Aug 2, 2014 at 4:13 PM
Edited Aug 2, 2014 at 4:18 PM
Sure, feel free to add me as a developer.

Regarding the solving process: maybe it would be better to let the Model assemble and store all data (matrices and vectors), let the solver take the model instance and produce a StaticLinearAnalysisResult. So the ISolver interface would contain a method like
StaticLinearAnalysisResult Solve(Model model);
This way you'd get a clearer separation of concerns. What do you think?

EDIT: I haven't looked at the classes in detail, so this is solely from a design perspective. Don't know if it fits into the overall finite element analysis process.
Aug 2, 2014 at 8:21 PM
Yes, you're right but actually my most important objective in designing classes was to hide things other than FEM from end user and make the whole package simple for use as i guess many users of the library are not familiar with difference of solvers and anything other than obvious things in FEM.
I think it would be good if make the different solvers option with a property of type enum (say for example SolverType enum have two values: CholeskyDecomposition and ConjugateGradient) and Model class have a property of type SolverType which have a default value (either cholesky or cg).
Anyways i'll try to implement the new solvers and solvers options into library in next days.

Thanks heaps!
Aug 4, 2014 at 3:03 PM
Edited Aug 4, 2014 at 3:08 PM
I've updated the code:

Model now contains two more Solve overloads:
  1. Solve(SolverConfiguration config, SolverType solverType) - the user can choose CholeskyDecomposition or ConjugateGradient as solver type.
  2. Solve(SolverConfiguration config, ISolver<double> solver) - the user might implement their own solver or use CholeskySolver or PCG from the Solver namespace.
I removed all references to the Cholesky decomposition (ie. the Model doesn't compute the decomposition and the StaticLinearAnalysisResult doesn't store it). I think, from a design perspective, this is the best way to go (decoupling the solving process from the model/storage).

Maybe SolverConfiguration should be renamed to LoadConfiguration.

I've also added proper copyright notices to the PCG and SSOR classes.

EDIT: if there's no use case for solvers with complex valued matrices, just remove the generics part from the ISolver interface.
Aug 9, 2014 at 6:04 AM
I've applied the codes with a little change.