Hi Cyril, if you only have the vertex ID, but nothing else, then viennagrid::find() is all that is left. The reason is that vertex IDs do not have to be contiguous, so a direct array access is not always possible. You last code line can be simplified to PointType p = viennagrid::default_point_accessor(*viennagrid::find(mesh, VertexIDType(cell_point_ID)); Best regards, Karli
Hi, you need to convert your compressed_matrix to a std::vector< std::map<unsigned int, ScalarT> > matrix first. Something like this: std::vector< std::map<unsigned int, ScalarT> > temp(vcl_matrix.size1()); viennacl::copy(vcl_matrix, temp); viennacl::io::write_matrix_market_file(temp, "sym_matrix_p.mtx", 1); (I agree that this conversion should happen automatically inside the matrix-market writer, but nobody has requested it so far). Best regards, Karli
Hi tario, you need to make sure that all source files that include ViennaCL with CUDA enabled carry the .cu file extension. Otherwise, the CUDA-compiler will parse the code as normal C++ code, hence the errors. Best regards, Karli
Hi tario, ad 1): What do you mean? krylov_dim is a local variable, so you can definitely overwrite it with whatever value you prefer. Make sure that your temporary work arrays are appropriately sized, though (that is, making krylov_dim smaller is no problem, but making krylov_dim larger than the initial value requires a larger set of Krylov vectors). ad 2): cr looks alright. However, your cr_min and cr_max are likely to be wrong, because cos() takes radians instead of degrees. Note: i += i; looks...
Thanks, tario, for the suggestion. I have a couple of questions: 1.) In what way is the current "Installation" in the online manual insufficient? http://viennacl.sourceforge.net/doc/manual-installation.html It describes just the steps you mentioned above? 2.) The suggested code is actually not too different from what is in examples/benchmark/solver.cpp - apparently it's not prominently placed. Did you find that example at all? 3.) Would you watch a youtube video for a library installation? I think...
Are you sure that the system you hand over to CG is symmetric positive definite? Slow convergence all the way to stagnation may happen with CG, yes. The zigzag-pattern you describe is, however, unusual.
Hi, you definitely need to fix the invalid read and writes. The uninitialized values reported should also be fixed, yet I don't think that they are the reason for the issues you observed with CG. Best regards, Karli
Hi, I have not seen such a behavior before. Can you run your code through valgrind (or similar) in order to check for memory corruption? Do you use a preconditioner (if so, which)? Best regards, Karli