FEKO caught signal 22. SIGABRT signal received

Altair Forum User

Hi,

 

I combined MoM with RL-GO in my electrically large model. I selected large flat surfaces of the model and chose the option of solving it with RL-GO.

 

I then meshed the model, the resultant mesh looked great! The total number of unknowns reduced from >200k to about >80k.

 

While running the solver, I got this message:

 

--- Processing frequency 1 of 8 ( 1.18000E+08 Hz)

+++ Processing configuration: StandardConfiguration_008

FEKO caught signal 22 (PID 3344)

SIGABRT signal received, exiting

 

...and then the simulation stopped. I can't find anything in the manual or the internet about this SIGABRT or signal 22. 

 

Any idea on what that is and why the simulation stopped running?

 

Thanks!

JIF

Hello shashank119,

 

Are you using a full commercial version or a student version? Maybe you ran into a limit of the EDU version (https://altairuniversity.com/feko-student-edition/)? Are you running on a cluster? Maybe your time on the cluster ran out? These are all guesses, since FEKO would usually give more detailed information in addition to the SIGABRT message that indicates what caused it. Do you have more info in the output that you didn't include in your post?

 

Are you able to send the model so that we can try to reproduce it?

 

Altair Forum User

Hello JIF,

 

I have a full version. Unfortunately, I can't provide the model due to the nature of my work.

 

The only info I can think of adding on is that i'm solving the model at 8 discrete frequencies. It started processing 1st of 8 frequencies and then came up with FEKO caught signal 22. Couldn't be time out as I've run longer models using HOBF that took 2 days and progressed very slowly.

 

Any other possibilities? Is it anything to do with solving specific surfaces using RL-GO?

 

Perhaps, some of the surfaces that I've set to using RL-GO is attached to very small geometry. I was wondering if that could be a reason for some sort of internal error for FEKO to abort?

 

Altair Forum User

Hi shashank119,

 

We have internal mechanisms to track internal errors that would give clear indications of what went wrong, or the nature of the signal.  Floating point exceptions for instance would be apparent to us from the FEKO error code clearly reported in the OUT-file. Your output does not show a FEKO error code, just a signal number.

 

You did not say what type of system you are working on, is this a cluster environment where there are job schedulers involved that might kill the job or is this a PC that you use locally for your models?

 

My suspicion is this might have been a signal sent by the operating system. Do you see this error consistently and always at the same place?

Altair Forum User

Hi Renier,

 

This is a PC that I use locally for my models. This error is consistent for this particular model only. and yes, at the same place. Pops up right after processing 1st of the 8 frequencies.

 

This is only occurred when I set specific faces to be solved using RL-GO. 

 

For the exact same model, if I disregard RL-GO and use MLFMM instead, it works fine. I just wanted to use RL-GO and verify if the results converge.

 

 

JIF

Hello shashank19,

 

I understand that you can't share the model, but are you able to reproduce the same problem in a smaller, simplified model that you are able to share?

What version of FEKO are you using?

 

We have never seen an error like this and would really like to investigate it further, but without a model, we can't seem to reproduce the problem and thus we can't fix it or give you advice.

 

Altair Forum User said:

Perhaps, some of the surfaces that I've set to using RL-GO is attached to very small geometry.

Are the RL-GO faces in contact with the MoM faces? This is not allowed (or should not be allowed). Maybe that is what is causing the problem?