Discussion Forum

Hi

your image does not tell much about your model though ;)

But, a "0" on the diagonal often indicates some non defined BC's or not enough Boundary conditions to solve correctly. Now you have also a segregated solver case, perhaps the unknown comes from the 2nd step and has not been caclualted, or that the initial values are too far from the final solution.

I can suggest: a) recheck all your BCs for all physics, ahve you defined enough PER physics ? b) check the initial conditions, are these reasonnable ("0" is seldom the most reasonable, once you know the model, but in all generalit for any type of model "0" is an as good guiess, now I hope that you have a specific model and that you have done your home works with a few expecedd values where to pass ...) c) try to use adirect solver (or move all unknown to step 1 and suppress step 2... (requires more RAM, OK for small models on large PC)

--
Good luck
Ivar

Hi Ivar,

thanks so much for your good suggestions,

and I'd like to attach my model file, and could you please take a look, it is headache for me for a long time.

The model is basically a 3D germanium diode.
the top left is P region, and top right is N region.
the substrate is P-type also.

the Va is applied voltage change form 0 to 1.

due to this is high nonlinear problem, so a electrical static is calculated first to find the initial value.

the first step works fine.
it gives the potential display.

but the second step have problem of coupling.

could you please help me with this?

--
learn COMSOL, like COMSOL

Hi

I do not have COMSOL access from home, I'll take a look on Monday, perhps I find something

--
Good luck
Ivar

thanks a lot

--
learn COMSOL, like COMSOL

Hi

I had a very quick first look, as your model is complex with several physics, it's demanding to identify what's wrong. The error message concerns the segregation group 1 your diffusion analysis.
I tried also to run it in a "direct" mode without segregation steps, the error was oscillating over 1:1E14, so it looks like there is still a missing BC, that I suspect in the diffusion model, or something in the input/initial values used for the cn/cp models

One more point: Your diffusion model is only based on standard concentration flux based "diffusion" you have not turned on the Electric driven diffusion (main physics node), isn't your charge density driven by the E field ? and are you sure you have "standard diffusion" of any significant level. Check how it changes the equations of your physics

--
Good luck
Ivar

Hey, I just spent an hour debugging a "Matrix has zero on diagonal" error. No problem with BCs. The problem was that I spelled the unit GHz as ghz. Units are case sensitive, it appears, and if you misspell them COMSOL can give a "zero on diagonal" error. Hope this helps somebody.

Great program, but the error messages suck.

--
C

Units are indeed case sensitive, just like the rest of the program. When you think about it, it has to be that way, otherwise nothing would distinguish a megawatt from a milliwatt, a second from a siemens, etc.

Now, at least in the current version, version 4.3, if you type "ghz" as the unit for a quantity, that quantity gets highlighted in orange and the message "unknown unit" is displayed when you move the mouse over it. It's easy to spot and interpret.

Hi Jean-François

I agree it helps, but in a complex model when you are looking for "any orange anywhere" you spend a lot of time,

Perhaps some CNTR-F find text in the model tree could help (still need to know what you are looking for) or a scan model tree command to find inconsistencies, too run through all but have COMSOL looking deep under ?

It's just like when you by error hit an internal COMSOL variable name, we do not always get an error flag, as its permitted to re-affect given variables, here too it would be nice to have a command "check variable naming collisions", and get a list of variables that might interfere.

I'm talking about true multiphase models, with 2-3 or more screen hight of model tree nodes (I'm, still missing sub "folder" nodes to group my physics and Results nodes into digestible chunks) but the new option sort by dimension is nice ;)

--
Good luck
Ivar

Dear Users,

I am having a similar kind of error while simulating Navier-Stokes in a channel adjacent to a porous media. The error message goes as follows when using BicGStab solver: "Error 6247: Matrix has zero on diagonal for the SSOR update submatrix in the Vanka algorithm" .

I tried to solve this via changing some solver settings but could not get out of it except having a different error message "Error: 6177 Matrix has zero on diagonal."

Hoping that you can help me out.

Thanks,
Ashwini

Hi

normally "zero diagonal matrix" means you are missing some BC or initia lconditions such to make your equation set unique. I would start searching in that direction. Check carefully that al (and EACH)l dependent variable have enough BC's w.r.t. equation level/order. In multiphysics it's easy to forget one, and some physics have several dependent variables in addition to the one you are perhaps "onlx" using / interested in

--
Good luck
Ivar

Hi Ivar,

Thanks for your prompt response. I tried according to your suggestion and checked each and every boundary and initial condition. Since my problem concern only one physics, i.e., momentum transport and a cubical geometry, it was rather easier for me. Anyways, I could not find any inconsistency there.

An interesting thing which I just came across is that I can solve the same problem using a direct PARDISO solver. However, I am reluctant to pursue that since BicGStab is the default solver for momentum transport. What do you suggest?

Thanks in advance,
Ashwini

Hi

if you have enough RAM to solve with a direct sover, it should be OK, I do not know of any specific limitations of the validity of a results if it solves correctly with one rather than another solver,

but I do neither not know all the subtilities of the numerous solvers COMSOL has, ready to be used
and I donormally not bother to change the solvers, appart if he default one fails
--
Good luck
Ivar

Actually I have this problem in CFD. Running using Direct solver cleared it.

Would you say that this suggests that sometimes it arises not from missing boundary conditions?

It is nice to have a lot of RAM so that the direct solver is an option.