There is no failure. There is clearly nothing wrong with the boundary 
conditions because your boundary conditions are satisfied in both cases.

You're not solving the same problem. charge, electrons, holes, idonors, and 
iacceptors are not arbitrary values. They are densities. Printing 
holes.cellVolumeAverage et al. shows that the charge is not balanced when you 
pluck cell 7, but it is when you pluck cell 6. The specific issue is that your 
criterion x < (L / 2. - dep) cuts off cells with centers less than 4. In the 
pluck-cell-6 case, that includes the merged cell 6+7 with a center at 3.5, but 
in the pluck-cell-7 case, that does not include the merged cell 7+8 with a 
center *at* 4. You have lost the holes between 3.5 and 4 that would be in your 
uniform solution. 

I seriously doubt that there is any numerical method that can account for not 
discretizing your data consistently.


On Jan 16, 2014, at 8:05 PM, "[email protected]" <[email protected]>
 wrote:

> Hello Daniel,
> 
> Thanks for the insight, having a large project which is still light weight 
> and transparent is a challenge so I understand that approach.
> 
> My interest in the CV approach came about because my 1D FVM code fails when 
> trying to solve a particular electrostatics problem. I coded up the same 
> problem in Fipy and it also fails. After asking around I believe this is a 
> fundamental problem with the FVM method related to the way Dirichlet boundary 
> conditions are enforced with the CC-FVM; they are enforced weakly by using 
> the Dirichlet condition to calculate the flux at the boundary face. My hope 
> was that by switching to a CV-FVM, where the domain will be terminated not by 
> faces but by cell values, the Dirichlet conditions can be enforced strongly. 
> Of course this makes Neumann conditions cumbersome to implement.
> 
> Did you ever run into any fundamental breakdown of the numerical method in 
> your FVM research?
> 
> For more info here is a Fipy script that shows the failure,
> https://gist.github.com/danieljfarrell/8466479
> 
> Also here is a more formal write up of the problem which show the same 
> failure with my code,
> http://scicomp.stackexchange.com/questions/8577/peculiar-error-when-solving-the-poisson-equation-on-a-non-uniform-mesh-1d-only
> 
> As for the next step I'm a bit unclear how to solve this problem (other than 
> what I mentioned above), maybe a finite element approach is needed?
> 
> Best wishes,
> 
> Dan
> 
> PS. I realise this is a bit off-topic, but maybe it will be of interest to 
> the developers of numerical methods which are subscribed rather than the Fipy 
> users.
> 
> On 17 Jan 2014, at 06:55, Daniel Wheeler <[email protected]> wrote:
> 
>> On Mon, Jan 13, 2014 at 10:33 PM, [email protected]
>> <[email protected]> wrote:
>>> Dear list,
>>> 
>>> When reading through the FiPy docs, 
>>> http://www.ctcms.nist.gov/fipy/documentation/numerical/discret.html
>>> 
>>> I noticed that discussion of vertex centred (CV) and cell centred (CC) 
>>> meshes. I'm just curious, why did you decided to implement FiPy with CC 
>>> approach. Did you find some advantages? I can't find much information on 
>>> the internet discussion the advantages/disadvantages other than the storage 
>>> argument.
>> 
>> My background was in CC methods so that is mostly why FiPy uses this
>> method. I think I'm right in saying that VC is probably more involved
>> in terms of coding as sub cells need to be constructed. It seems that
>> if you go to the trouble of VC, you may as well program a full FEM.
>> The point of FiPy is to be faily light weight and transparent so that
>> it is quite easy to understand its different parts. VC would be moving
>> away from this philosophy.
>> 
>> As far as the relative merits are concerned, I am not really sure off
>> hand. As you say, VC may require more storage, but also has better
>> accuracy on unstructured grids. In terms of publications, it seems
>> like I see a lot more CC rather than VC  on the whole if that counts
>> for anything
>> 
>> Sorry I can't be more specific.
>> 
>> -- 
>> Daniel Wheeler
>> 
>> _______________________________________________
>> fipy mailing list
>> [email protected]
>> http://www.ctcms.nist.gov/fipy
>> [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
> 
> 
> _______________________________________________
> fipy mailing list
> [email protected]
> http://www.ctcms.nist.gov/fipy
>  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]


_______________________________________________
fipy mailing list
[email protected]
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

Reply via email to