[begou]

I get a problem with wmkdep. This application recurse in the included file to build the dependance list for each file to compile. The algorithm opens many and many files (following the recursivly included files) and reach the system limits.

My default configuration was 100 open files in a session. I asked the admin for an increased limit up to 500, but 500 seams also to low for some OpenFOAM files !

Isn't it posible to modify this behavior of wmkdep ? On some super-computer with a lot of users, administrators may not accept to increase the maximum number of simultanous open files.

OpenFOAM: OpenFOAM-1.6.x
OS: Suse SLES10
Hardware: SGI Altix450


Patrick

[gschaider]

Originally Posted by begou

I get a problem with wmkdep. This application recurse in the included file to build the dependance list for each file to compile. The algorithm opens many and many files (following the recursivly included files) and reach the system limits.

My default configuration was 100 open files in a session. I asked the admin for an increased limit up to 500, but 500 seams also to low for some OpenFOAM files !

Isn't it posible to modify this behavior of wmkdep ? On some super-computer with a lot of users, administrators may not accept to increase the maximum number of simultanous open files.

OpenFOAM: OpenFOAM-1.6.x
OS: Suse SLES10
Hardware: SGI Altix450


Patrick

Have you tried "ulimit -n 1000" yourself? That should extend the number for the current shell

Bernhard

[begou]

Originally Posted by gschaider

Have you tried "ulimit -n 1000" yourself? That should extend the number for the current shell

Bernhard

You can't increase the limit set by the system administrator. You are only allowed to lower it (from 800 to 600 open files for example).

[olesen]

Originally Posted by begou

The algorithm opens many and many files (following the recursivly included files) and reach the system limits.
...
Isn't it posible to modify this behavior of wmkdep?

When you change wmkdep, I think that easiest would be to introduce a local (singly) linked list of filenames.

Instead of triggering nextFile() immediately for each "#'include" lex, you would simply add them into the linked-list. When the lexer hits the local EOF, you would then fclose() this file handle before walking through the list.
For each name in the list, open it and repeat the procedure of lexing and creating the linked-list etc.
You would retain the recursive behaviour, the hash table (to avoid unnecessary lookups) but only have a single file handle open ever.

This would not only solve your problem, but if done correctly would also eliminate the current limit of 300 open files that is hard-coded in the wmkdep source.