Dear all,
can I still use this implementation to output the material_ids together
with the updated DataPostprocessor class?
Thanks.
Best,
Tuanny
On Sunday, August 14, 2016 at 3:54:18 PM UTC+2, Pete Griffin wrote:
>
> Thank you Daniel for your response.
>
> I took a while since I was trying to implement something that was similar
> to the post you pointed to by Philip Wardlaw, but was as requested by
> Wolfgang's response a little more general. I looked on git but did not know
> how to search to find what he may or may not have posted by him.
>
> I have minimally modified four files that are attached (data_out.h,
> data_postprocessor.h, data_out.cc and data_postprocessor.cc). The
> modifications start and end with "//#### Start" or "//#### End". Their is
> an addition of an enum in data_out.h. The same could be done for the other
> places build_patches() is used like data_out_faces() etc. but I am not sure
> whether would be useful since I am not familiar with them.
>
> typedef enum
> {
> no_data,
> material_id_data,
> user_index_data,
> pointer_data, // not implemented
> } ExtraDataOut;
>
>
> The value of the enum is passed from user code to build_patches () as an
> unsigned int. I guess ideally it would be an DataOut<dim>::ExtraDataOut but
> my C++ was not good enough to have the enum known to
> DataPostprocessor<dim>. The new call to build_patches() would be:
>
> for HP code:
> data_out.build_patches (ndiv, DataOut<dim>::user_index_data); // not yet
> mapping_collection
> or NON-HP code:
> data_out.build_patches (mapping, ndiv, DataOut<dim>::curved_inner_cells,
> DataOut<dim>::user_index_data);
>
> In both cases the final new parameter defalts to DataOut<dim>::no_data. I
> created two new functions:
> compute_derived_quantities_scalar_with_data ()
> compute_derived_quantities_vector_with_data ()
> with the data item returned as an unsigned long long int to accomadate a
> 64 bit pointer and kept the original ones as is:
> compute_derived_quantities_scalar ()
> compute_derived_quantities_vector ()
>
> When attempting to have just one I got the warning related to "hidden
> funtion" that I was not able to get rid of so I created another name for
> the new one which for me worked fine.
>
> I have "make clean debug" and "make release run" the following steps:
> step-18, 17, 8, 27, 30, 6 and 51 and my extended step-8 with HP, NON-HP
> and MPI/PETSc using the original compute_derived_quantities_vector() and
> new compute_derived_quantities_vector_with_data() without issues. All
> extended step-8 gave the same numerical results, considering HP/NON-HP.
>
> I hope this will be useful to others.
>
> Pete Griffin
>
>
> On Saturday, August 6, 2016 at 4:29:46 PM UTC-4, Daniel Arndt wrote:
>>
>> Pete,
>>
>> I remember someone having something like this in mind. This is the link
>> to that discussion:
>> https://groups.google.com/forum/#!topic/dealii/QKuDndKojug
>>
>> A different way would be to derive from DataOut and overwrite
>> DataOut::first_cell and DataOut::next_cell by skipping all the cells that
>> don't have a specific material_id.
>> If you do this for each material_id, you could create an output file for
>> each material_id and join them afterwards. This would be similar to how you
>> combine output from different MPI processes using a pvtu file (step-40).
>>
>> Best,
>> Daniel
>>
>
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
