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();



Hi,
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?
Regards



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.



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:
brieffiniteelmentnetSolver20140804.zip
Model now contains two more Solve overloads:
Solve(SolverConfiguration config, SolverType solverType)  the user can choose
CholeskyDecomposition or ConjugateGradient as solver type. 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.



Hi,
I've applied the codes with a little change.
Thanks

