When was this "field-within-group by field-within-group" performed? Since I am using libmesh-0.9.3 which was downloaded in 2013, I am not sure whether this new ordering has been updated.
On the other hand, another important question to me is: As I have multi-variable at hand: u_x, u_y, u_z. I want to use a block type matrix to store these vars, such as the "baij" type in PETSc. But -mat_type baij does not work. I found something like "LIBMESH_ENABLE_BLOCKED_STORAGE". How can I use the block type matrix? Thanks. Luo Li > -----原始邮件----- > 发件人: "Roy Stogner" <royst...@ices.utexas.edu> > 发送时间: 2015年12月3日 星期四 > 收件人: "David Knezevic" <david.kneze...@akselos.com> > 抄送: li....@siat.ac.cn, libmesh-users <libmesh-users@lists.sourceforge.net> > 主题: Re: [Libmesh-users] Default ordering of multi-variables in a system? > > > On Thu, 3 Dec 2015, David Knezevic wrote: > > > On Thu, Dec 3, 2015 at 10:08 AM, Roy Stogner <royst...@ices.utexas.edu> > > wrote: > > > > On Thu, 3 Dec 2015, li....@siat.ac.cn wrote: > > > > > I have a question on the default ordering of multi-variables in a > > > system, e.g. u_x, u_y and p in Navier-Stokes equaiton. Is the > > > default ordering of unknowns (1) node by node with each node has > > > all variables; or (2) field by field with each field (like, u_x) > > > has all node's values ? > > > > The outermost ordering is always processor-by-processor: e.g. degree > > of freedom indices owned by MPI rank 0 will always have lower numbers > > than dof indices owned by rank 1. > > > > The default ordering within each processor's dofs is field by field. > > > > If you want node-by-node ordering (still within each processor's dofs) > > then you can pass the argument "--node_major_dofs" on the command > > line. > > > > If all variables are the same type, then I thought "node major dofs" is the > > default. I thought this was changed when Ben added the blocked-dofs > > optimization. I could be mis-remembering though? > > Ah, hell - I think you're right! Thanks for the correction! > > Okay, here's where it gets trickier. > > The default ordering isn't "processor by processor, then field by > field, then node by node" anymore; now it's "processor by processor, > then variable group by variable group, then node by node, then > field-within-group by field-within-group". Variable groups are > collections of field variables which all have the exact same > structure (same FE type and supported on the same subdomains), and > libMesh now creates variable groups automatically when you add > identically structured variables contiguously. > > So if we imagine the u_x, u_y, p case, the variable ordering actually > depends on whether you're using equal-order stabilized elements or > Taylor-Hood elements! In the former case you'll get node-by-node > ordering; in the latter case on each processor's block you'll get > node-by-node ordering of u_x,u_y but then all the p dofs will be at > the end. > --- > Roy -- Li Luo https://sites.google.com/site/rolyliluo/ Shenzhen Institutes of Advanced Technology Address: 1068 Xueyuan Avenue, Shenzhen University Town, Shenzhen, P.R.China Tel: +86-15899753087 li....@siat.ac.cn ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
