I think I understand my problem (slowly):
Using the project-function means that I write the initial conditions into 
my solution-vector. But when I call fe_values[N_density] I get a view on 
the finite element-variable, which is not connected to the solution-vector. 
Thus I get (in the last line) the value of the i-th degree of freedom at 
the q-point-th point in the grid. Now, when iterating over the degrees of 
freedom, the first degree of freedom will be in x-direction (if looking in 
a cartesian coordinate system), the next one in y-direction and the last in 
z-direction, thus being the base vectors for a 3d grid, but they are not 
connected to the values set before in the project-function. Is that 
correct? Or did I still misunderstand something?

Am Samstag, 5. August 2017 12:34:30 UTC+2 schrieb Jean-Paul Pelteret:
>
> Dear Maxi,
>
> Aligned with Wolfgang's thoughts (and considering your recent flurry of 
> posts), it seems like you need to slow down and more carefully consider 
> what you are doing in your work. We all have to work through bugs and 
> conceptual issues - this is part of learning both the deal.II, or any 
> library for that matter. In 99% of cases the documentation (manual + 
> tutorials) does a good job of explaining not only what any particular 
> function does but also how its used in context. Its up to you to ensure 
> that you've done your best to understand that context. Where it fails to be 
> help, we're here and happy to clarify. Not all of the information is in the 
> tutorials that may be directly relevant to your work (such is the 
> philosophy of our tutorial structure) - one often has to do a bit of 
> leg-work to find it.
>
> So, I'm not going to answer your question directly, but rather I'm going 
> to pose a couple of questions to you:
> 1. In this line
> VectorTools::project(dof_handler, constraint_matrix, QGauss<dim>(3), 
> InitialValues<dim>(carrier_density), solution);
> where is the projected function being output/stored?
> 2. What type of object does 
> fe_values[N_density]
> return?
> 3. What information are you asking for here?
> fe_values[N_density].value(i, q_point)
> 4. Are what you doing in (1) and (3) in any way related? If not, then why 
> not? What is the disconnect?
>
> I'd be happy to direct you to an example in the tutorials that, to the 
> best of my understanding of what you're trying to achieve, demonstrates the 
> mechanism to extract the information that you're trying to get at.
>
> Best,
> Jean-Paul
>
>
> On Saturday, August 5, 2017 at 10:18:44 AM UTC+2, Maxi Miller wrote:
>>
>> I tried to debug it (thus the reason for "volatile"), and reduced the 
>> whole code down to (called in SetupSystem()):
>>
>>         
>> VectorTools::project(dof_handler, constraint_matrix, QGauss<dim>(3), 
>> InitialValues<dim>(carrier_density), solution);
>>         //For checking of content
>>         const FEValuesExtractors::Vector N_density(N_component);
>>         const FEValuesExtractors::Vector E_temperature(TE_component);
>>         const FEValuesExtractors::Vector L_temperature(TL_component);
>>         const QGauss<dim> quadrature_formula(fe_degree+1);
>>         const unsigned int dofs_per_cell = finite_element.dofs_per_cell;
>>         const unsigned int n_q_points    = quadrature_formula.size();
>>         FEValues<dim> fe_values(finite_element, quadrature_formula,
>>                                       update_values | update_gradients | 
>> update_JxW_values);
>>         std::vector<Tensor<1, dim>> value_N(dofs_per_cell), value_TE(
>> dofs_per_cell), value_TL(dofs_per_cell);
>>         for (auto cell = dof_handler.begin_active(); cell!=dof_handler.
>> end(); ++cell)
>>         {
>>
>>             fe_values.reinit (cell);
>>
>>             for (unsigned int q_point=0; q_point<n_q_points; ++q_point)
>>             {
>>                 for(size_t i = 0; i < dofs_per_cell; ++i)
>>                 {
>>                     std::cout << "Value_N[" << i << "] = " << fe_values[
>> N_density].value(i, q_point) << '\n';
>>                     getchar();
>>                       value_N[i] = fe_values[N_density].value(i, q_point
>> );
>>                       value_TE[i] = fe_values[E_temperature].value(i, 
>> q_point);
>>                       value_TL[i] = fe_values[L_temperature].value(i, 
>> q_point);
>>                 }
>>             }
>>         }
>>         //Content checking end
>> Furthermore, I checked (via break points) how the values are set in 
>> InitialValues<>:
>>    
>>  template <int dim>
>>     double InitialValues<dim>::value(const Point<dim> &p, const unsigned 
>> int component) const
>>     {
>>         (void) p;
>>         Assert(component < this->n_components, ExcIndexRange(component, 0
>> , this->n_components));
>>         if(component < dim)
>>             return equations.initial_carrier_density;
>>         else
>>             if(component < 2*dim && component >= dim)
>>                 return equations.ambient_temperature;
>>             else
>>                 return equations.ambient_temperature;
>>     }
>>
>>     template <int dim>
>>     void InitialValues<dim>::vector_value(const Point<dim> &p, Vector
>> <double> &values) const
>>     {
>>         for(size_t i = 0; i < this->n_components; ++i)
>>             values(i) = InitialValues<dim>::value(p, i);
>>     }
>>
>> and according to the debug output, every value was set correctly in that 
>> function. Nevertheless in the debug output code above I still get (for the 
>> first point, and the first values of i and j: 
>>  Value_N[0] = 0.324665 0 0
>>
>> Value_N[1] = 0 0.324665 0
>>
>> Value_N[2] = 0 0 0.324665
>>
>> Value_N[3] = 0 0 0
>>
>> Value_N[4] = 0 0 0
>>
>> Value_N[5] = 0 0 0
>>
>> Value_N[6] = 0 0 0
>>
>> Value_N[7] = 0 0 0
>>
>> Value_N[8] = 0 0 0
>>
>> Value_N[9] = -0.0412379 0 0
>>
>> Value_N[10] = 0 -0.0412379 0
>>
>> Value_N[11] = 0 0 -0.0412379
>>
>> Value_N[12] = 0 0 0
>>
>> Value_N[13] = 0 0 0
>>
>> Value_N[14] = 0 0 0
>>
>> Value_N[15] = 0 0 0
>>
>> Value_N[16] = 0 0 0
>>
>> Value_N[17] = 0 0 0
>>
>> Thus: Is there a misunderstanding in how the data is stored, or how the 
>> data is processed? According to my understanding the values should be 1e18 
>> at every point. Is that correct? Or is there a better way to debug my code?
>>
>>
>> Am Freitag, 4. August 2017 23:48:08 UTC+2 schrieb Wolfgang Bangerth:
>>>
>>> On 08/04/2017 09:49 AM, Maxi Miller wrote: 
>>> > 
>>> > Why is there only one value not equal to zero, and why is it moving? 
>>> Shouldn't 
>>> > all the values be set already? 
>>>
>>> Maxi -- this is not a question to which you can expect an answer on the 
>>> mailing list. We are happy to help with conceptual questions, but you do 
>>> need 
>>> to debug your code yourself. 
>>>
>>> (I will note that there is almost never a reason to mark variables as 
>>> 'volatile' as you do. It's not wrong -- it just doesn't have any effect 
>>> in 
>>> this context at all.) 
>>>
>>> Best 
>>>   W. 
>>>
>>> -- 
>>> ------------------------------------------------------------------------ 
>>> Wolfgang Bangerth          email:                 bang...@colostate.edu 
>>>                             www: 
>>> http://www.math.colostate.edu/~bangerth/ 
>>>
>>>

-- 
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.

Reply via email to