Console.cpp issues

[Unknown]

Dear,

I have been struggling to integrate the Fuzzylite to my simulator Castalia, so far there is an error related to the Console.cpp under Fuzzylite src folder.

In order to link the Fuzzylite to my simulator Castalia, I have added the following bold line in the makemake file under Castalia,

#!/bin/bash

ROOT=pwd

# The following options are used by OMNeT’s opp_makemake tool
# For explanation and a complete list of options run: opp_makemake -h
OPTS=” -f -r –deep -o CastaliaBin -u Cmdenv -P $ROOT -M release”

# -X excludes a directory from being considered
EXCLUDEDIRS=” -X Simulations -X out -X bin”

# Use options -I -L -l to include external header files or libraries

EXTOPTS=”-I /home/utar/Desktop/HY/fuzzylite-6.0/fuzzylite/ -L /home/utar/Desktop/HY/fuzzylite-6.0/fuzzylite/release/bin/ -lfuzzylite”

# Run OMNeT’s opp_makemake tool with the above options
opp_makemake $OPTS $EXCLUDEDIRS $EXTOPTS

Then while the compilation runs smoothly, the simulation simply cannot be run. After tracing the file, I am able to trace the source of problem which results from Castalia bin file that is written in Python. The following is the snippet of code that concerns me :

r_castalia = re.compile(“^Castalia\|\s+(.+)$”)
r_scenario = re.compile(“Scenario:\s(.*)\$repetition=(\d+)$”)
r_progress = re.compile(“^\*\* Event \#\d+\s+T=(\S+)\s+Elapsed: (\S+)s.+\s(\d+)\% completed”)
r_newrun = re.compile(“Preparing for running configuration General, run #(\d+)”)
r_totalrun = re.compile(“Number of runs: (\d+)”)

for ini in iniList:
ini_num += 1
baselabel = label = labelList.pop(0)
f = open(“omnetpp.tmp”,”w”)
f.write(“[General]\n”)
f.write(“repeat = ” + str(options.repeat) + “\n”)
for k in sorted(ini.keys()):
f.write(k + ” = ” + ini[k] + “\n”)
f.close();
has_output = 0
if sys.version_info > (2,7):
data = subprocess.check_output([pathToCastaliaBin, ‘-f’, ‘omnetpp.tmp’, ‘-x’, ‘General’]).split(“\n”)
else:
data = subprocess.Popen([pathToCastaliaBin, ‘-f’, ‘omnetpp.tmp’, ‘-x’, ‘General’], stdout=subprocess.PIPE).communicate()[0].split(“\n”)

if len(data) > 6: data = data[6]
else: data = “”

m = r_totalrun.match(data)
if (m):
runs = “/” + m.group(1)
else:
print “WARNING: unable to determine total simulation runs”
runs = “”

Having spent some time figuring out the problem, it is learnt that the variable data shows the following output by using print function:

data is [‘[option error] option <-f> not recognized’, ‘{at /src/Console.cpp::parse() [line:134]}’, ”, ”]

Turns out the so-called /src/Console.cpp does come from the Fuzzylite, therefore I wish someone can explain to me how Fuzzylite works so that I may be able to solve my problem. Thanks very much.

Best regards,
Yeon

[Juan Rada-Vilela (admin)]

Hi Yeon,

thank you so much for your detailed post.

It seems to me that the entry point for Castalia is being taken as the entry point of the fuzzylite library.

I believe the behaviour you want with data = subprocess.check_output([pathToCastaliaBin, ‘-f’, ‘omnetpp.tmp’, ‘-x’, ‘General’]).split(“\n”) is to execute Castalia and not fuzzylite. It seems that the binary is executing the main method of the fuzzylite library.

To address this, I suggest that you exclude the main.cpp file from building in your project.

Hope this works. Let me know if it does not.

Cheers.

Juan

[Unknown]

Dear Juan,

First of all, thanks very much for your prompt reply.

However, after removing the main.cpp under the src file, the problem still remains the same.

I have no idea why it would execute the Fuzzylite code because the pathToCastaliaBin is supposed to link /home/utar/Desktop/Castalia/CastaliaBin which is to execute the omnetpp.tmp file.

The full content of omnetpp.tmp is shown as follows:

[General]
repeat = 1
SN.field_x = 100
SN.field_y = 100
SN.node[*].Application.collectTraceInfo = true
SN.node[*].Application.constantDataPayload = 2000
SN.node[*].Application.packet_rate = 1
SN.node[*].Application.rng-0 = 3
SN.node[*].ApplicationName = “ThroughputTest”
SN.node[*].Communication.MAC.backoffType = 2
SN.node[*].Communication.MAC.collectTraceInfo = true
SN.node[*].Communication.MAC.dutyCycle = 1.0
SN.node[*].Communication.MAC.randomTxOffset = 0
SN.node[*].Communication.MAC.rng-0 = 4
SN.node[*].Communication.MAC.rng-1 = 5
SN.node[*].Communication.MACProtocolName = “TunableMAC”
SN.node[*].Communication.Radio.RadioParametersFile = “../Parameters/Radio/CC2420.txt”
SN.node[*].Communication.Radio.collectTraceInfo = true
SN.node[*].Communication.Radio.rng-0 = 2
SN.node[*].Communication.Routing.collectTraceInfo = true
SN.node[*].Communication.Routing.netBufferSize = 1000
SN.node[*].Communication.Routing.percentage = 0.05
SN.node[*].Communication.Routing.powersConfig = xmldoc(“powersConfig.xml”)
SN.node[*].Communication.Routing.roundLength = 20s
SN.node[*].Communication.Routing.slotLength = 0.2
SN.node[*].Communication.RoutingProtocolName = “LeachRouting”
SN.node[*].MobilityManager.rng-0 = 0
SN.node[*].ResourceManager.collectTraceInfo = false
SN.node[*].ResourceManager.rng-0 = 6
SN.node[*].SensorManager.collectTraceInfo = false
SN.node[*].SensorManager.rng-0 = 7
SN.node[*].SensorManager.rng-1 = 8
SN.node[0].Communication.Routing.isSink = true
SN.node[0].xCoor = 0.0
SN.node[0].yCoor = 0.0
SN.node[10].xCoor = 0.0
SN.node[10].yCoor = 90.0
SN.node[1].xCoor = 50.0
SN.node[1].yCoor = 0.0
SN.node[2].xCoor = 60.0
SN.node[2].yCoor = 0.0
SN.node[3].xCoor = 70.0
SN.node[3].yCoor = 0.0
SN.node[4].xCoor = 80.0
SN.node[4].yCoor = 0.0
SN.node[5].xCoor = 90.0
SN.node[5].yCoor = 0.0
SN.node[6].xCoor = 0.0
SN.node[6].yCoor = 50.0
SN.node[7].xCoor = 0.0
SN.node[7].yCoor = 60.0
SN.node[8].xCoor = 0.0
SN.node[8].yCoor = 70.0
SN.node[9].xCoor = 0.0
SN.node[9].yCoor = 80.0
SN.numNodes = 11
SN.physicalProcess[*].rng-0 = 10
SN.wirelessChannel.bidirectionalSigma = 0
SN.wirelessChannel.collectTraceInfo = true
SN.wirelessChannel.onlyStaticNodes = true
SN.wirelessChannel.pathLossExponent = 2.0
SN.wirelessChannel.rng-0 = 1
SN.wirelessChannel.rng-2 = 9
SN.wirelessChannel.sigma = 0
cmdenv-event-banners = false
cmdenv-express-mode = true
cmdenv-interactive = false
cmdenv-module-messages = true
cmdenv-performance-display = false
ned-path = ../../src
network = SN
num-rngs = 11
output-scalar-file = Castalia-statistics.sca
output-vector-file = Castalia-statistics.vec
seed-set = ${repetition}
sim-time-limit = 2000s

As you can see, I suspect if it is the problem of ned-path = ../../src. However, provided that pathToCastaliaBin does not relate anything to fuzzylite, I think my concern here is redundant. Any idea how it relates to Fuzzylite ? In other words, anything I can do to track how it runs into fuzzylite?

[Unknown]

Dear Juan,

First of all, thanks very much for your prompt reply.

However, even I removed the file, the problem still remains the same.

The only things that confuses me is that : Why is it running into FuzzyLite’s console.cpp ???

[Juan Rada-Vilela (admin)]

Hi,

I am as confused as you are.

Can you print the value of the ‘pathToCastaliaBin’ to make sure you are pointing to the castalia binary and not fuzzylite’s binary?

Else, my guess is that you built your project and either the entry points (namely ‘main(char** args)’ of fuzzylite and castalia got mixed up, or the fuzzylite entry point in ‘main.cpp’ is being called from castalia entry point.

By default, the entry point of fuzzylite is the console.

[Juan Rada-Vilela (admin)]

Have in mind that, if the entry points got mixed up, and you deleted the ‘main.cpp’ you will still need to clean and rebuild your project.

[Unknown]

Dear Juan,

Yes, the value of CastaliaBin is : /home/utar/Desktop/Castalia/CastaliaBin

Yes, I do agree very much with you that it may have mix entry point because there is no way it can execute Fuzzylite with CastaliaBin path. For the pathToCastaliaBin, ‘-f’, ‘omnetpp.tmp’, ‘-x’, ‘General’ with subproces.check_output, and I have verified that -f and -x options are actually used for Castalia.

By the way, I tried to compare the output of $PATH between the one excludes Fuzzylite and the one include Fuzzylite after executing Castalia. The outputs are same and are shown as follows:

/usr/local/cuda-8.0/bin:/usr/local/cuda-8.0/bin:/home/utar/bin:/home/utar/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/utar/Desktop/HY/fuzzylite-6.0/fuzzylite/:/home/utar/omnetpp-4.6/bin:/home/utar/Desktop/Castalia/bin

Does it mean the path for executing the bin file remains unchanged ? If so, how would it run into Fuzzylite ?

Regarding the rebuild, if I remove the main.cpp, it would fail to build with the build.sh under fuzzylite folder. So what should I do ?

[Juan Rada-Vilela (admin)]

How about running manually from console the /home/utar/Desktop/Castalia/CastaliaBin without parameters?

I do not know what Castalia is, but did you recompile Castalia? Is it software you are building from sources?

My thoughts on this would be to print information to console from the main entry points of both castalia and fuzzylite. And then to debug the projects and find out what is happening.

[Unknown]

Dear Juan,

To my surprise, when I typed /home/utar/Desktop/Castalia/CastaliaBin on the terminal, it shows :

========================================
fuzzylite: a fuzzy logic control library
version: 6.0
author: Juan Rada-Vilela, Ph.D.
license: FuzzyLite License
========================================

usage: fuzzylite inputfile outputfile
or: fuzzylite benchmark engine.fll input.fld runs [output.tsv]
or: fuzzylite benchmarks fllFiles.txt fldFiles.txt runs [output.tsv]
or: fuzzylite [-i inputfile] [-if format] [-o outputfile] [-of format] [-example letter] [-decimals number] [-d file] [-values number] [-scope scope] [-dheader boolean] [-dinputs boolean]

where:
-i inputfile file to import your engine from
-if format format of the file to import (fll | fis | fcl)
-o outputfile file to export your engine to
-of format format of the file to export (fll | fld | cpp | java | fis | fcl)
-example letter if not inputfile, built-in example to use as engine: (m)amdani or (t)akagi-sugeno
-decimals number number of decimals to write floating-poing values
-d file if exporting to fld, FLD file of input values to evaluate your engine on
-values number if exporting to fld without datafile, number of results to export within scope (default: EachVariable)
-scope scope if exporting to fld without datafile, scope of -values: [EachVariable|AllVariables]
-dheader boolean if true and exporting to fld, include headers
-dinputs boolean if true and exporting to fld, include input values

Visit http://fuzzylite.com/ for more information.

Copyright (C) 2010-2017 by FuzzyLite Limited.
All rights reserved.

Obviously, it certainly comes from the console.cpp.

Yes, I would compile every times I make any changes to figure things out. I would need to use command line ./makemake -> then make , then it would run the compilation. But when I want to run the simulation, which I need to type Castalia -i leach.ini -c General, this problem occurs.

I agree with you. In Castalia python file, I did use print method to debug the code, I did the same to Console.cpp. As I have been using this Castalia for quite a while, I know how it works. However, since I am very new to Fuzzylite, I only know how to compile the Fuzzylite but I have no idea how it works. In other words, I would like to know more as to how Fuzzylite feeds inputs, how it generates outputs, in what way Console.cpp comes into play, where is the main code user has to look into and so on. The only thing I know from Fuzzylite Documentation is how to compile it and set up linker, which is certainly limited, therefore I wish you can help explain and elaborate more so that we both can save time of each other. I would really appreciate it. Thanks in advance.

[Unknown]

This is just the screen shot I forgot to upload.

[Author]

Posts