On 7/18/12 2:51 PM, "Roy Stogner" <royst...@ices.utexas.edu> wrote:
>> Yeah, I still use these, and would miss them if they were gone! > > Any chance I could talk you into not missing them? Or learn from you > why you prefer dphidx[i][qp] over dphi[i][qp](0)? One of these days > I'd like to add additional compile-time options for our FE data arrays > (mostly to enable users to fix those stride problems and/or use third > party multiarray classes), and it would be convenient to get rid of > the redundant data at the same time while I was digging around in that > code. OK, I take it back. What I'd truly miss are my C-ish #define macros, which currently do the right thing anyway: #undef phi #undef dphi #undef dphidx #undef dphidy #undef dphidz #define phi(i) (this->phi_values[i][qp]) // Real #define dphi(i) (this->dphi_values[i][qp]) // Gradient #define dphidx(i) (this->dphi_values[i][qp](0)) // Real #define dphidy(i) (this->dphi_values[i][qp](1)) // Real #define dphidz(i) (this->dphi_values[i][qp](2)) // Real So I'd miss my dphidx(n), which is not in fact what Paul was referring to - I am not in fact using the libMesh-provided dphidx etc... arrays. (yes, I know there are all kinds of reasons why I shouldn't use those macros...) I could see a case in the future though why it might be useful to pack phi, dphidx, JxW, etc... into simpler data types, for example to pass to a legacy matrix assembly code or do horribly expensive matrix assembly in CUDA or something. But in that case I'd think we'd do it on demand in a single function, and would be able to avoid the proliferation of duplicate data that seems to be at issue here. -Ben ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
